Hallo ich schildere einfach mein Ziel: mehrere AVR-Webserver empfangen über ihre serielle Schnittstelle Daten von Sensoren, z.B. Temperatur. Diese Server sollen dann die Daten speichern, bis sie von einem Zentralserver aufgefordert werden, ihre Daten an diesen zu übermitteln und dann kann der Speicherplatz auf den AVR-Servern wieder frei gegeben werden. Der Zentralserver soll die Daten dann in eine SQL Datenbank speichern. Welches AVR-Ethernet-Board würdet ihr für den Einstieg empfehlen. Wie realisiert man dann die Kommunikation zwischen den Servern? Ich freue mich auf jede Hilfe. Viele Grüße Richi
Gast
#1818854
Ein Pollin Net-IO wäre für den Einstieg sicher das einfachste. Die Messwerte kannst du direkt mit Bordmitteln übertragen. Statt einer HTML-Seite liefert das Net-IO Board beim Aufruf von seinem Webserver eine CSV-Datei, die die Messwerte enthält. Der Hauptserver fragt per Crontab & Wget alle Boards ab und holt sich so die Messwerte. Den Ordner voller CSV-Dateien lässt du dann per Script in die Datenbank schreiben. Beim Seitenabruf wird auf dem Atmega sicherlich eine Funktion aufgerufen werden, an die du dich anhängen kannst. Sobald der Abruf passiert ist, löscht du die alten Datensätze und beginnst, die Sensoren neu abzufragen. Problematisch wird es erst, wenn du die Daten sicher übertragen musst. Dann müsstest du eine eigene Kommunikation vorsehen, bei der beide Server über Prüfsummen und Statusmeldungen sicherstellen, dass die Daten übertragen und gespeichert wurden.
also sicher sollte die Übertragung schon sein, falls du damit meinst, dass die Werte richtig übergeben werden.
hallo, meinst so was http://birne.altmuehlnet.de/hp/px5/logger/avr.php mfg
wenn er die Tempereaturen auch über einzelne Server einliest, dann ja.
wäre es nicht auch möglich, dass die kleinen Server immer, wenn neue Daten anstehen, diese sofort dem Zentralserver schicken, und zwar indem sie eine php-Seite aufrufen, von der aus die in der Adresse übergebenen Daten in die Datenbank eingelesen würden? Ich weiß allerdings nicht, ob es möglich ist, dass der AVR-Server eine Internetseite aufruft. Viele Grüße Richi
Gast
#1819125
>Ich weiß allerdings nicht, ob es möglich ist, dass der AVR-Server eine >Internetseite aufruft. Ein Server ruft keine Internetseiten auf, er liefert welche. Das ist der kleine Unterschied.
Kommt draufan was man als Server sieht. Hier wird gerade vom Server als Gerät in Form eines NetIO gesprochen, der Server der Daten nur ausliefert ist die Software, das is dann auch nochmal ein kleiner Unterschied ;)
Gast
#1819172
>Hier wird gerade vom Server als Gerät in Form eines NetIO gesprochen, >der Server der Daten nur ausliefert ist die Software, das is dann auch >nochmal ein kleiner Unterschied ;) Richtig. Und die ganzen Deppen glauben das so ein kleiner AVR Wunderdinge tun kann: >und zwar indem sie eine php-Seite aufrufen, Dann bringen wir dem AVR mal PHP bei.
Er will doch nur ne Seite AUFRUFEN, nich darstellen. Mit Ullis FW geht das glaub, läuft aber nur wenn du nen Mega644 anstatt des 16er benutzt da der zu wenig Speicher hat.
genau, ich will nur eine Seite aufrufen, also z.B abc.de?a=1&b=2 die Seite speichert dann a und b in eine Datenbank. Es geht also nur darum, ob es der AVR schafft, eine Seite aufzurufen. Das anzeigen wird nicht verlangt. Vielleicht gibt es ja noch einfachere Lösungen, wobei ich denke, dass diese Lösung recht einfach zu realisieren wäre. Viele Grüße Richi
Gast
#1819306
Die Radigsche Firmware enthält eine Funktion zu Übermittlung von Daten per HTTP-Get. Angucken lohnt sich auf jeden Fall. Vermutlich kann man die Firmware auch soweit reduzieren, dass nur noch die GET-Methode übrig bleibt.
Ich bin mir nicht sicher, aber ist die http-get-Funktion nicht eine zum empfangen von Parametern?
Du willst die Daten ja nicht in einem Browser anzeigen, wozu dann die Daten in HTTP verpacken? Definier dir dein eigenes Protokoll und sende es über TCP.
oder benutze RS485 anstelle von Ethernet. Dan schaft das jeder µC ( und der Programierer auch).
Es ist so, dass ich mir wahrscheinlich einen Server mieten werde, daher fällt RS485 raus. Kann man dann auch hier noch sein eigenes Protokoll machen?
Richard W. schrieb: > Kann man dann auch hier noch sein eigenes Protokoll machen? Ja. +-+ +-+ +-+ +-+ +-+ +-+ | | | | | | | | | | | | Sensoren + µC +++ +++ +++ +++ +++ +++ | | | | | | +----+----+-+--+----+----+ RS485 | +-+-+ | | großer µC oder PC +-+-+ | | Ethernet | Internet Ich meinte sowas!!!
Gast
#1819910
>Ich bin mir nicht sicher, aber ist die http-get-Funktion nicht eine zum >empfangen von Parametern? Jein. HTTP unterscheidet zwischen POST- und GET-Methode. Bei der POST-Methode werden die Daten in der Nachricht verschickt. Bei der GET-Methode werden die Daten in der URI verschickt (?x=xy&y=yx...) Siehe Wikipedia: http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Argument.C3.BCbertragung Manche Server möchten ihre Parameter per POST andere per GET bekommen. Manche verstehen auch beides. Parameter per GET zu verschicken ist einfacher als per POST. Bei GET muss man nur die URI erzeugen und an den Server schicken. POST erfordert mehr Aufwand. Und diese Methode unterstützt Ulrich Radigs Firmware halt.
hallo, blick immer noch nicht durch was du genau willst. wieso server mieten und wieso nicht wire bus? http://bauerer.dyndns.org/daten.html http://bauerer.dyndns.org/ mfg orfix
> wieso server mieten und wieso nicht wire bus? Wenn man einen Server mietet (oder kostenlosen nimmt, gibts evt.) muss man sich um nichts kümmern. Und was ist wenn meine Miniserver meilenweit auseinander stehen???, dann funktioniert es mit deinem Bus nichtmehr. Die AVRs sollen keine Webseiten anzeigen können müssen, sondern nur die Daten an den gemieteten Server schicken, welcher diese dann in eine Datenbank speichert.
Gast
#1820006
Erba57 Ba schrieb: > http://bauerer.dyndns.org/ Bei den acht 1-Wire-Temperatursensoren steht überall bei MAX(Tag) 85.0. Hmm, da passt was nicht, oder?
mit welcher Funktion von Ulrich Radig kann man denn jetzt eine HTTP-Seite aufrufen, also nicht laden; nur aufrufen?
Gast
#1820304
>mit welcher Funktion von Ulrich Radig kann man denn jetzt eine >HTTP-Seite aufrufen, also nicht laden; nur aufrufen? Wo ist da der Unterschied?
ich meine nicht anzeigen, also nur die URL senden.
Gast
#1820337
Gehen wir doch mal zu deinem Ursprungspost: >Diese Server sollen dann die Daten >speichern, bis sie von einem Zentralserver aufgefordert werden, ihre Aha, der Zentralserver fragt die Daten ab. Schon mal gar nicht schlecht. Da kannst du über den AVR-Webserver HTML, CSV oder was weiss ich was Dateien zurücksenden. Erfordert dann aber eine Auswertung auf der Serverseite. Fragt der Zentralserver die Daten nicht ab und die AVR-Webserver sollen die Daten einfach so senden, dann denk mal über E-Mail oder FTP nach. Erfordert dann aber eine Auswertung auf der Serverseite. Wo ein Wille ist ist auch ein Weg.
es muss nicht unbedingt sein, dass der Zentralserver die Daten abfrägt. Es wäre mir mitlerweile sogar lieber, wenn die AVR-Server selbstständig senden würden. Was mich auch reizen würde, wäre dass der Zentralserver dem AVR zuvor noch sagen kann, was er senden soll. Meinermeinung am eifachsten ist es für die Einwegübertragung (AVR->Zentralserver), wenn der AVR eine auf dem Zentralserver laufende php-Seite aufruft, indem er in der URL die Parameter übergibt, und dann diese per php in die Datenbank eingetragen werden. Viele Grüße Richi
Richard W. schrieb: > ich meine nicht anzeigen, also nur die URL senden. Dann kannst du aber Ulrichs Software nicht einfach so einsetzen. Die ist nun mal ein Server. D.h. die wartet darauf, dass irgendjemand an sie eine GET Aufforderung schickt und nicht umgekehrt. Aber so schwer sollte das dann auch wieder nicht sein. In der Software ist ja die ganze TCP/IP Geschichte schon erledigt. Daraus kann man sicherlich etwas bauen, wenn manns kann (und da wird dann die Gretchenfrage liegen) Verbindung aufbauen: IP und Port sind ja bekannt dann einen GET mit den Parametern schicken (ist ja nur reine Textübertragung) Alles was vom Server zurückkommt einfach ignorieren
also von dem ganzen Protokoll habe ich nicht viel Ahnung. In Ulrichs Software gibt es ja auch eine Funktion für http-get. Ist nur die Frage, ob die auch das bewirkt, was ich will. Ausseheh tuts auf jeden Fall so.
Ich habe noch ein wenig durch Ulrichs Seite geblättert und bin fündig geworden. Sein Server unterstützt das Empfangen von Seiten. Somit ist theoretisch auch die beidseitige Abfrage möglich (bidirektional). Soll ich denn das Pollin-Board oder das Radig-Board (welches von den beiden) nehmen?
Gast
#1820428
Bleibt noch das Problem, dass du deinen Server (gemietet) vermutlich nie erreichen wirst. Denn das NET-IO kommt einfach nicht über den Router hinaus. Denn du hast keine IP im I-Net, die für deinen Miniserver registriert ist. Denke ich zumindest. Wenn du dann noch ne Identifikation mitschickst wird's spannend. Ach ja, sobald du draußen bist, werden Spaßvögel über dich herfallen und Müll an deinen Server senden. Früher oder später. Das musst du dann auch irgendwie abfangen.
Hat nicht mein Router eine IP. Wenn ich dann dort die entsprechenen Ports öffne, kann ich normalerweise schon auf meinen AVR zugreifen. Man kann ja auch seinen eigenen PC zum FTP-Server umbauen, indem man ein Programm installiert und entsprechende Ports freigibt.
Gast
#1820587
>Hat nicht mein Router eine IP. Wenn ich dann dort die entsprechenen >Ports öffne, kann ich normalerweise schon auf meinen AVR zugreifen. Je, genau. Das funktioniert dann mit solchen Anbietern wie Dyndns.org, bei denen sich dein Router beim IP-Wechsel meldet und seine aktuelle IP hinterlässt. Angesprochen wird dein Webserver dann über eine Subdomain von Dyndns. In die andere Richtung geht das sogar noch einfacher, da dann nur eine einfach TCP-Verbindung zu deinem Zentralserver aufgebaut werden muss. Gewisse Sicherheitsmechanismen solltest du schon vorsehen...
Welche Sicherheitsmechanismen meinst du denn?
Gast
#1820786
Wenn ich dich richtig verstanden habe, dann gehe mal von folgendem Aufbau aus: Deine Mini-AVR-Systeme sind bei dir (zuhause?) im lokalen Netz und schicken die Messwerte per z.B. per HTTP-GET oder -POST an einen (gemieteten) Server, irgendwo bei einem Provider in Internet. Auf diesem Server läuft ein PHP-Skript, dass die Daten entgegen nimmt und in eine SQL-Datenbank speichert. Dann braucht dein Mini-AVR-System gar keine feste IP über irgendeinen Dynamic-DNS Dienst. Es muss nur die IP-Adresse vom Gateway (deimem Router) kennen. Die URL des Servers im Internet muss er natürlich auch kennen, und sie ist auch fest. Allerdings kenne ich die Radig-FW nicht und weiß nicht, ob sie DNS unterstützt oder nur IP-Adressen. Deshalb gehe ich jetzt einfach mal davon aus, das ersteres der Fall ist. Wenn du dir die Messwerte nun anschauen willst greifst du einfach per Webbrowser von jedem beliebigen PC der Welt auf deine gemieteten Server im Internet zu. Dort wird dann ein zweites PHP-Skript ausgeführt, dass die Daten wieder aus der SQL-Datenbank ausliest und in Browser anzeigt.
Genau, so will ich es. Brauche ich dann noch Sicherheitsmechanismen, wenn ja welcher Art? Und welchen AVR-Server soll ich mir anfangs kaufen?
STK500-Besitzer schrieb: >>Hat nicht mein Router eine IP. Wenn ich dann dort die entsprechenen >>Ports öffne, kann ich normalerweise schon auf meinen AVR zugreifen. > > Je, genau. > Das funktioniert dann mit solchen Anbietern wie Dyndns.org, bei denen > sich dein Router beim IP-Wechsel meldet und seine aktuelle IP > hinterlässt. > Angesprochen wird dein Webserver dann über eine Subdomain von Dyndns. > In die andere Richtung geht das sogar noch einfacher, da dann nur eine > einfach TCP-Verbindung zu deinem Zentralserver aufgebaut werden muss. > Gewisse Sicherheitsmechanismen solltest du schon vorsehen... ist doch Käse, für was brauchter denn dyndns ... er möchte das sein AVR-NET-IO nen GET Request http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP-Request-Methoden an seinen webspace sendet (!) und nicht eine Seite hosten. Auf seinem Server macht er n kleines php-Script, dass dann die $_GET in ne SQL schreibt ... Die Frage ist nun, ob das NET-IO nen http://meineseite/script.php?variable=x via Router ins www schicken kann. Der Server bekommt dann schon aus den $_SESSION oder $_SERVER die IP des Routers. Die andere Variante wär die Messwerte in ne Seite auf dem NET-IO zu integrieren, diese dann per Cronjob vom Server her abfragen zu lasse, die Seite zu parsen und dann die Werte zu schreiben. So mach ichs im Übrigen und geht auch, dann braucht man aber die IP des Routers im www um connecten zu können. Das kann man mit dyndns machen, wenn man aber eh php-Funktionalität auf seinem Webspace hat kann man das auch mit nem kleinen Script machen, dass der Router beim Connecten aufruft. Meine Anwendung: http://www.jungwinzer-hochstadt.de/Bilder/chart/chart_x2.php?dayoffset=2 da sind 4 LM75 am NET-IO für die Messwerte
Also mittlerweile bin ich mir ziemlich sicher, dass ich mit Radigs Software einen GET-Request senden kann. Normalerweise müsste dann alles klappen. Welchen Server soll ich denn nun kaufen, möchte nämlich so bald wie möglich das testen können. Viele Grüße Richi
Testen würde ich das ganze erst mal Local - also mit einem Webserver auf dem eigenen PC im Netzwerk. Wenn das klappt, weißt Du auch, was Du benötigst. Testfall schrieb: > Denn das NET-IO kommt einfach nicht über den Router > hinaus. Denn du hast keine IP im I-Net, die für deinen Miniserver > registriert ist. Denke ich zumindest. Denkt er falsch. Denn auch Deine am Router angeschlossenen PCs haben keine offizielle IP. Und auch ohne Dyndns kann man dann surfen. Der Router macht eine Adressübersetzung. Die einzig Statische IP hat der Webserver. Die AVR-Boards sind nur Clients (Immer der, der die Verbindung aufbaut, ist der Client). Auch der Zentral-'server' wäre eigentlich nur Client, wenn er die Informationen von den AVRs abrufen würde. Dann benötigst Du aber wirklich für jeden seperat im Netz sitzenden AVR einen dyndns-account. Sinnvoll ist es aber immer mehrere Clients zu haben, die auf einen Server zugreifen, als umgekehrt. Interessant wäre es nun, auf so einem AVR, neben dem TCP-Stack noch PPPoE zu implementieren - dann würdest Du nicht mal mehr den Router benötigen. Obwohl ... DSL ist dafür ja gar nicht nötig, so viele Daten müssen da doch bestimmt nicht übertragen werden. Um die Sicherheit des Servers sollte sich Dein Provider kümmern. Du musst dann nur dafür sorgen, daß Dein PHP-Datenempfangsskript nicht angreifbar ist. Oder dafür sorgen, daß es niemand ausser Dir findet. Bei den Clients (AVRs) solltest Du einfach keine eingehende Verbindung zulassen - auch nicht, wenn das Paket behauptet schon eine Verbindung mit dem Client zu haben ... etc. Gruß Jobst
Das einfachste wäre wohl einfach den Microcontroller eine E-Mail abschicken zu lassen. Das ist ziemlich einfach (einfacher als HTTP) und zuverlässig. http://de.wikipedia.org/wiki/SMTP-Auth Der große Vorteil dabei ist, dass das Timing weitgehend vom Mikrocontroller bestimmt wird. Sprich wenn Du beispielsweise die Daten von 10 Minuten aufzeichnest, so kannst Du die einfach wegschicken, ohne auf irgendwelche Clients warten zu müssen. Wenn Du als Server arbeitest, so kann es sein, dass Dein Client mal irgendwie keine Verbindung mit Dir aufbaut, oder dies aus irgendwelchen Gründen 5 Minuten später macht. Dann müsstest Du noch mehr Werte zwischenspeichern können.
Wahrscheinlich werde ich den von Pollin nehmen, der ist günstiger und Ulrichs Software läuft darauf auch. Oder will mir jemand einen anderen empfehlen?
Ich weiß nicht, wie gut die Software vom Pollin ist, so weit wie ich weiß macht die nur einen Server und auch nur über IPv4. Eventuell wäre das hier besser: http://www.sics.se/~adam/uip/index.php/Main_Page oder hier einer für IPv6 http://www.sics.se/contiki/contiki-6lowpan-uipv6-faq.html
Jobst M. schrieb: > Dann benötigst Du > aber wirklich für jeden seperat im Netz sitzenden AVR einen > dyndns-account. nein, brauchste nicht ... ein dyndns und der Rest geht über Ports und Portforwarding
Gast
#1822112
>Jobst M. schrieb: >> Dann benötigst Du >> aber wirklich für jeden seperat im Netz sitzenden AVR einen >> dyndns-account. >nein, brauchste nicht ... ein dyndns und der Rest geht über Ports und >Portforwarding Nur, wenn alle AVR hinter dem gleichen Router sitzen, also im Internet die gleiche IP haben. >Interessant wäre es nun, auf so einem AVR, neben dem TCP-Stack noch >PPPoE zu implementieren - dann würdest Du nicht mal mehr den Router >benötigen. Der arme AVR. Worum der sich alles kümmern soll. >Wahrscheinlich werde ich den von Pollin nehmen, der ist günstiger und >Ulrichs Software läuft darauf auch. >Oder will mir jemand einen anderen empfehlen? Für deine Tests solltest du dir am besten gleich zwei Boards bestellen.
Gast
#1822127
Fhutdhb Ufzjjuz schrieb: > STK500-Besitzer schrieb: >>>Hat nicht mein Router eine IP. Wenn ich dann dort die entsprechenen >>>Ports öffne, kann ich normalerweise schon auf meinen AVR zugreifen. >> >> Je, genau. >> Das funktioniert dann mit solchen Anbietern wie Dyndns.org, bei denen >> sich dein Router beim IP-Wechsel meldet und seine aktuelle IP >> hinterlässt. >> Angesprochen wird dein Webserver dann über eine Subdomain von Dyndns. >> In die andere Richtung geht das sogar noch einfacher, da dann nur eine >> einfach TCP-Verbindung zu deinem Zentralserver aufgebaut werden muss. >> Gewisse Sicherheitsmechanismen solltest du schon vorsehen... > > ist doch Käse, für was brauchter denn dyndns ... > > er möchte das sein AVR-NET-IO nen GET Request > http://de.wikipedia.org/wiki/Hypertext_Transfer_Pr... > an seinen webspace sendet (!) und nicht eine Seite hosten. Das war mir schon klar. Es war eine Antwort auf seine Frage >>Hat nicht mein Router eine IP. Wenn ich dann dort die entsprechenen >>Ports öffne, kann ich normalerweise schon auf meinen AVR zugreifen. Um auf den AVR von aussen zugreifen zu können, braucht man dyndns. Und das System von dyndns habe ich kurz erklären wollen. > Auf seinem Server macht er n kleines php-Script, dass dann die $_GET > in ne SQL schreibt ... > Die Frage ist nun, ob das NET-IO nen > > http://meineseite/script.php?variable=x > > via Router ins www schicken kann. Der Server bekommt dann schon aus > den $_SESSION oder $_SERVER die IP des Routers. > > > Die andere Variante wär die Messwerte in ne Seite auf dem NET-IO zu > integrieren, diese dann per Cronjob vom Server her abfragen zu lasse, > die Seite zu parsen und dann die Werte zu schreiben. > So mach ichs im Übrigen und geht auch, dann braucht man aber die > IP des Routers im www um connecten zu können. > Das kann man mit dyndns machen, wenn man aber eh php-Funktionalität > auf seinem Webspace hat kann man das auch mit nem kleinen Script > machen, dass der Router beim Connecten aufruft. > > Meine Anwendung: > http://www.jungwinzer-hochstadt.de/Bilder/chart/ch... > > da sind 4 LM75 am NET-IO für die Messwerte Schönes Ding!
Richard W. schrieb: > Genau, so will ich es. > Brauche ich dann noch Sicherheitsmechanismen, wenn ja welcher Art? Ja. An Deinen Server kann ja jeder x-beliebige einen http-get schicken und damit Werte in Deiner DB speichern. Du brauchst also auch noch eine Art von Authentifizierung. Das Einfachste wäre, zusätzlichen einen Usernamen und ein Passwort beim http-get mitzusenden. Gruß, Frank
Frank M. schrieb: > Richard W. schrieb: >> Genau, so will ich es. >> Brauche ich dann noch Sicherheitsmechanismen, wenn ja welcher Art? > > Ja. > > An Deinen Server kann ja jeder x-beliebige einen http-get schicken und > damit Werte in Deiner DB speichern. Du brauchst also auch noch eine Art > von Authentifizierung. Das Einfachste wäre, zusätzlichen einen Usernamen > und ein Passwort beim http-get mitzusenden. Das kannst du dir aber auch sparen. Denn wenn jeder rauskriegen kann, wie der GET aussehen muss, um Werte in die DB zu speichern, kriegt er auch raus, wie Username und Password aussehen
Karl heinz Buchegger schrieb: > Das kannst du dir aber auch sparen. > Denn wenn jeder rauskriegen kann, wie der GET aussehen muss, um Werte in > die DB zu speichern, kriegt er auch raus, wie Username und Password > aussehen Es sei denn, dass durch irgendeinen Fehler der Angreifer Dein PHP-Skript lesen kann. Dann geht das sehr schnell.
Zusätzliche Authentifizierungswerte einbauen ist eigentlich immer gut. Ist ja kein großer Aufwand, deswegen werde ich das auch machen.
Gast
#1822228
>Das Einfachste wäre, zusätzlichen einen Usernamen >und ein Passwort beim http-get mitzusenden. Das wird als Klartext übertragen... Also entweder ein "Rundsteuer-Passwort", das sich regelmäßig ändert, oder keins...
Naja, Du könntest ja auch einfach folgendes machen: 1. Du schickst eine Zufallszahl an den Server, der Server schickt das durch eine Hashfunktion und antwortet Dir. Du überprüfst das Ergebnis. 2. Der Server schickt Dir auch eine Zufallszahl (kann schon bei der Antwort auf 1 passieren) und Du schickst das durch die Haschfunktion und antwortest dem Server, wenn die vorherige Antwort des Servers korrekt war. Im einfachsten Falle geht das über einen Prüfsummenalgorithmus, wie beispielsweise MD5. Du nimmst die Zufallszahl, nimmst einen Schlüssel, welcher auf beiden Seiten bekannt ist, hinzu und führst den Algorithmus auf dieses Ergebnis aus. Dadurch kommt dann niemals der Schlüssel über das Netz.
Gast
#1822258
Christian Berger schrieb: > Naja, Du könntest ja auch einfach folgendes machen: > > 1. Du schickst eine Zufallszahl an den Server, der Server schickt das > durch eine Hashfunktion und antwortet Dir. Du überprüfst das Ergebnis. > 2. Der Server schickt Dir auch eine Zufallszahl (kann schon bei der > Antwort auf 1 passieren) und Du schickst das durch die Haschfunktion und > antwortest dem Server, wenn die vorherige Antwort des Servers korrekt > war. > > Im einfachsten Falle geht das über einen Prüfsummenalgorithmus, wie > beispielsweise MD5. Du nimmst die Zufallszahl, nimmst einen Schlüssel, > welcher auf beiden Seiten bekannt ist, hinzu und führst den Algorithmus > auf dieses Ergebnis aus. Dadurch kommt dann niemals der Schlüssel über > das Netz. Dann könnte man auch gleich den Zentralserver die AVRs abfragen lassen. Die lassen sich nämlich sehr einfach per Passwort schützen. Ausserdem könnte man dann auch gleich Router nehmen, die SSH-Tunnel unterstützen.
Jungs. Lasst doch die Kirche im Dorf. Er hat Schwierigkeiten einen normalen GET auf den Weg zu bringen und ihr schlagt hier Hin-und-her Authentifizierungssysteme vor.
Wenn er mit HTTP-Get Schwierigkeiten hat, dann würde ich ihm wirklich E-Mail anraten, das ist deutlich einfacher als HTTP.
ich glaube nicht, dass irgendeiner Lust und Mühe hat, meine Seite zu knacken, wenn ich einfach mehrere Parameter einbaue. Auf meiner Seite wird er sowiso nichts top-secret finden.
Das einfachste ist wie immer: Solange niemand weiß, dass es da einen Zugang zu einer DB gibt, strengt sich auch niemand an. Wenn also die Parameter beim GET nicht stimmen, pappst du eine Default-Seite hoch und kein Mensch wird auf den Gedanken kommen, da großartig PHP Code analysieren zu müssen um rauszufinden, wie er Werte in deine DB einschmuggeln kann. An dieser Stelle gilt: Fehlermeldungen machen einen zufälligen Besucher nur neugierig.
Gast
#1822454
Christian Berger schrieb: > Wenn er mit HTTP-Get Schwierigkeiten hat, dann würde ich ihm wirklich > E-Mail anraten, das ist deutlich einfacher als HTTP. Glaub ich nicht. Wenn der TCP-Stack fix und fertig ist wie in diesem Fall, dass ist das Schreiben auf einen TCP-Socket etwa so aufwändig wie einen Text über einen UART auszugeben. Ok, eine kleine State-Machine für den Verbindungsaufbau kommt noch dazu, aber das ist nun auch kein Problem. Serverseitig denke ich ist ein PHP-Skript einfacher zu implementieren als die Messwerte auf irgendwelchen eingegangenen Emails herauszuparsen. Ach ja, einen Mailserver müsstest du dann zusätzlich auch noch aufsetzen. Christian Berger schrieb: > Der große Vorteil dabei ist, dass das Timing weitgehend vom > Mikrocontroller bestimmt wird. Das ist bei einem HTTP-Get auch der Fall.
Habe jetzt gerade den Pollin-Server gekauft, ich hoffe es war die richtige Entscheidung! Viele Grüße Richi
Richard W. schrieb: > Auf meiner Seite wird er sowiso nichts top-secret finden. Nein, aber man kann ihn für seine Zwecke nutzen. Das ist viel interessanter. Findest Du bestimmt nicht witzig, wenn man Dir eines Tages vorwirft, Spam zu versenden. Oder Urheberrechtsverletzung, weil Du auf Deinem Server Filme zum Download anbietest. Naja, derart komplex wird Dein Script aber wohl nicht werden, daß man den Server damit Hijacken kann. Aber auf jeden Fall solltest Du im Script alle Zeichen escapen, die der Datenbankanfrage gefährlich werden könnten. Tipp: Passwort für Datenbank und für Zugang zum Server unterschiedlich wählen! Ich würde den Clients ein 'Secret', also einen Geheimen Text mitgeben. Von allen Daten zuzüglich dem Secret wird eine Prüfsumme (MD5) gebildet. Daten und Prüfsumme werden zum Server geschickt. Dieser speichert dies alles (evtl. auch IP und Zeit) Zusammen mit dem Secret kannst Du dann bei der Auswertung der Daten überprüfen, ob sie stimmen. Daten von irgendwelchen merkwürdigen IPs (z.B. aus China) kannst Du auch vorher schon verwerfen. Da ich nicht weiß, was Du anschliessend mit den Daten planst, kann ich allerdings nicht sagen, ob das praktikabel ist. Gruß Jobst
Hallo Richi, interessantes Vorhaben. Ich arbeite an einem sehr ähnlichen Projekt: also Daten messen und an einen Server senden, der sie speichert und eventuell grafisch darstellt. Ich habe mir auch das Pollin Board gekauft und mittlerweile die openMCP Software drauf am laufen. Das ging relativ einfach und die Software scheint viele Möglichkeiten zu bieten, wobei ich noch am erkunden bin. Zum Beispiel ist dort ein Twitter-Modul eingebaut, das man bestimmt umfunktionieren kann für einen eigenen Webserver, der die Daten empfängt. Wäre interessant wenn wir uns hier über die jeweiligen Erfahrungen austauschen können, speziell wenn Du auch die openMCP Software verwendest. Viele Grüße Christoph
Hallo Christoph ich brauche eigentlich nicht die ganzen Funktionen deiner verwendeten Software. Für mich ist dur das Aufrufen und dadurch das Übergeben der Daten an den großen Server von nöten. Ich denke ich werde dann aber bei Radigs Software bleiben. Wenn ich dir trotzdem helfen kann stehe ich dir natürlich offen (ich denke das Forum auch!!!) Viele Grüße Richi
Gast
#1831984
Hallo durch Zufall bin ich hier vorbeigekommen. Schau mal ob da was für dich dabei ist? http://www.tuxgraphics.org/electronics/200901/avr-ethernet-realtime.shtml Ich habe das aber nicht eingesetzt.......
Sucher schrieb: > durch Zufall bin ich hier vorbeigekommen. > > Schau mal ob da was für dich dabei ist? > > > > http://www.tuxgraphics.org/electronics/200901/avr-... > > > > Ich habe das aber nicht eingesetzt....... Glaube nicht dass ich was damit anfangen kann. Hab jetzt endlich Zeit gehabt, meinen Server zusammenzubauen. Auch Ulrichs Software läuft prima. (also die Standardseite wird angezeigt) Nun wollte ich aber wegen Speicherplatzsparen und der Übersichtlichkeit halber alles aus dem Code schmeissen, was ich nicht brauche, das wäre die komplette Webseitendarstellung und der ganze Schnickschnack (WoL...). Es soll praktisch nur noch das HTTP-Get-Feature übrig bleiben. Welche der Dateinen kann ich denn dann löschen? Viele Grüße Richi
Mir fällt gerade auf, dass man anscheinend die einzelnen Module aktivieren bzw. deaktivieren kann. Somit brauche ich mir gar nicht den Aufwand machen!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.