Hallo Leute :) Hat vielleicht jemand eine andere Version des http_get? Ich verwende den Webserver von Ulrich Radig und hier steht Testphase. Wenn ich mit Wireshark die Verbindung mit sniffere schreibt er mir ständig TCP Retransmission. Das heißt es funktioniert bei mir leider nicht :( Hat jemand einen Vorschlag :)? bitte um Hilfe mfg Hannes
> Hat vielleicht jemand eine andere Version des http_get? wget/http_get-und-wie-sie-alle heissen verwenden den TCP/IP Stack des zugrundeliegenden Betriebssystems. Damit die Flusssteuerung, die Pufferung (window sizes), die Round Trip Time Estimation... Daher: welches Betriebssystem, welches http_get genau? > Wireshark Und wo ist das Dump/PCap File? Ansonsten kann es nur Glaskugelauskuenfte geben.... > Das heißt es funktioniert bei mir leider nicht :( Was genau funktioniert nicht? Es kommen gar keine Daten an? Ein "Wireshark-Dump" mit einer vollen MTU snaplength waere sinnvoll! -Hans
Danke für die schnelle Antwort und Sie haben natürlich recht sorry ;) Angehängt hab ich jetzt meinen Code von Http_get. Ich habe hier den String für meinen Server geändert. Weiters noch die Wireshark Verbindung aber nur als Bild. Hoffe das passt :). Beim ersten Bild sende ich öfters Daten. Beim zweiten nur einmal. Was könnte schief laufen? http://www.ulrichradig.de/forum/viewtopic.php?f=27&t=993&p=3695&hilit=weather#p3695 Aus diesem Beitrag habe ich den Source genommen und verwende das http_get. Es ist ein Apache Server. Die Daten kommen am Server an, im Logfile schreibt er mir die Verbindung raus. Er interpretiert Sie falsch? Könnte ein Protokolleintrag fehlen? Danke für deine Hilfe. mfg Hannes
>> Hat vielleicht jemand eine andere Version des http_get? >wget/http_get-und-wie-sie-alle heissen verwenden den TCP/IP Stack >des zugrundeliegenden Betriebssystems. Damit die Flusssteuerung, >die Pufferung (window sizes), die Round Trip Time Estimation... >Daher: welches Betriebssystem, welches http_get genau? Der Radigsche Webserver hat kein Betriebssystem. Er basiert auf einem ATmega32 und einem ENC...-Ethernet-Chip. Das Ding gibt es in ähnlicher Ausführung bei Pollin unter der Bezeichnung "AVR NetIO". Mal sehen, wann ich wieder dazu komme, mich mit dem Webserver zu beschäftigen. Dann kann ich vielleicht auch eine Aussage dazu treffen. Funktioniert denn den Wetter.com-Abfrage, wie Ulrich Radig sie vorgesehen hat?
Der 192.168.0.25er macht nach dem durch das http_get empfangene TCP-SYN mit einem RST (und einem IMHO nicht standardkonformen ACK = RST+ACK) die Verbindung zu. Ergo: Der Webserver "ist kaputt" und man sieht ein "interessantes Verhalten" des Client TCP-Stacks (im ersten Bild wird ein RST (ohne ACK) gesendet). Die Aussage "Retransmission" ist ganz sicher falsch, denn das Paket wurde nicht vorher gesendet, wireshark behauptet das wohl wegen dem vorher gesehenen RST!? Ein PCAP/Dump File waere mir lieber gewesen, denn ein tcpdump (auf jedem vanilla Linux/Unix/SunOS) waere zur Diagnose besser (tcpdump -n -r <file>) (insbesondere versucht tcpdump keine eigenen Diagnosen :-) Probier' (entschuldigen Sie, im Forum wird allgemein geduzt) mal bitte mit einem Kreuzkabel. Passen die Media-Parameter (10Mbit, halb)? Gibt es diagnostische Ausgaben des embedded-Webservers? Woher kommen die malformed packets im Netzwerk?? (die waeren mit einem Kreuzkabel (hoffentlich) weg...) -Hans
Danke schonmal für deine Antwort Die neuen Tests kann ich leider erst am Freitag machen und ein PCAP/Dump File werde ich dann auch speichern. Ich hoffe du kannst mir dann noch helfen :) Der webserver is nicht embedded und läuft auf nem debian system. Ist ein apache und ich bezweifle das der kaputt ist. mfg Hannes
>Der webserver is nicht embedded und läuft auf nem debian system. >Ist ein apache und ich bezweifle das der kaputt ist. Bitte ein "netstat -an | grep LISTEN" auf dem debian System. Der 80/tcp ist nicht nur auf 127.0.0.1 gebunden (also *)? Bitte von einem anderen Windows/Linux System im Netz wie folgt testen: $ telnet 192.168.0.25 80 GET / HTTP/1.0 2 x Return Kommt nach dem telnet ein "Connection refused" oder nach der Eingabe von GET... und 2x Return ein HTTP-Header? Bei erstem ist das Problem klar, bei zweiterem haette ich gerne den genauen Inhalt des (ersten) SYN Paketes des embedded Rechners. -Hans
Ok vielen Dank :) kann doch schon morgen testen. Werde dann meine Ergebnisse posten. Danke und LG Hannes
Erstmals danke an Hans für deine Unterstützung. Es klappt nun mit dem angehängten Sourcecode. Man musste ein paar Kleinigkeiten am Server und im Programm ändern. Ich bekomme also nun meine Daten auf den Server. Leider kann ich immer nur senden wenn ich das Programm neu flashe. Das kann es ja nicht sein... Die Kommunikation funktioniert auch fast nie wenn ich einfach einen Reset mache. Was könnte hier mein Problem sein? Also angehängt hab ich jetzt die Ausgabe des uCs auf der seriellen Schnittstelle. Daten anfordern und die Antwort des Servers. Wenn ich nun noch einmal Daten sende bekomme ich zwar die Ausgabe: Daten anfordern aber keine Antwort des Servers und die Daten kommen auch nicht an. Hier muss ich nun neu flashe. Dann sendet er mir wieder einmal die Daten und dann geht wieder nichts. Hat jemand einen Ratschlag für mich? mfg Hannes
> Man musste ein paar Kleinigkeiten am Server und im Programm ändern. Diagnose? Was wurde geaendert? >Leider kann ich immer nur senden wenn ich das Programm neu flashe. Das >kann es ja nicht sein... >Die Kommunikation funktioniert auch fast nie wenn ich einfach einen >Reset mache. >Was könnte hier mein Problem sein? Ich gehe davon aus, dass Du den Webserver als OK diagnostizierst hast (was mir bei der Content-Length von 0 Stirnrunzeln verursachen wuerde). Da ich weiterhin kein PCAP von Dir (AARRRGH!) habe, reibe ich meine Glaskugel und rate anhand des Sourcecodes folgendes: - normalerweise wird vom Client ein ephemeral (quasi zufaelliger) Port genommen. Der ist bei Dir fix. Das wird so oder so Probleme ausloesen! - Im Code sehe ich nichts, was die Verbindung explizit schliesst. (im tcpdump PCAP wuerde man das mit einem 4 Way FIN Handshake sehen) - die Verbindung bleibt aus Sicht des Webservers bestehen - kommt eine neue Verbindung, wird ein RST aufgrund eines betshenden 4-Tupel (IPs,PORTs,IPd,PORTd) gesendet. Das RST sieht man in dem bereits gesendeten wireshark-Screenshot. - Du kannst das mit einem "netstat -an" ueberpruefen, in welchem TCP-Zustand der TCP-Automat ist --- nach der "erfolgreichen" Verbindung. - Normalerweise ist nach einer Verbindung der TCP-Automat fuer eine mindestens zweistellige Sekundenzeit in einem Zustand, der duplizierte oder spaet ankommende Pakete einer Verbindung behandeln soll. Diese Zeit ist in einem Linux Kernel Parameter gesetzt (-> googlen, normalerweise bei Unix um die 2 Minuten). Verifikation: Dein http_get laufen lassen, 2 Minuten warten, http_get laufen lassen. Erfolgreich? (Vermutlich brauchst Du 2 Minuten zum Flashen :-) Viele Gruesse, Hans PS: Deine bereitgestellten Infos sind echt mager!
Er schließt mir die Verbindung nicht. Sie bleibt immer bestehen. Ich muss irgendwie die Verbindung schließen. Eine Idee wie ich das im Code realisieren kann? Der Tipp von dir war richtig :)... An dem Problem scheiter ich aber leider noch :( Ich habe einmal anstelle des Connection: close ein Connection: Keep-Alive probiert. Nun funktioniert es nach jedem Reset. & der Server schließt nach einer Zeit die Verbindung automatisch. mfg Hannes
>Er schließt mir die Verbindung nicht. >Sie bleibt immer bestehen. >Ich muss irgendwie die Verbindung schließen. Im Code ist die Layer7-Applikation als FSM modelliert :-) D.h. verstehen und dann erweitern :-) >Eine Idee wie ich das im Code realisieren kann? Hir muesste jetzt jemand mitsupporten, der den benutzten TCP/IP Stack kennt. Da gibt es aber auch noch weitere Unschoenheiten, wie: Der Clientcode sollte auf RST reagieren (und eine Fehlermeldung im Debug Output schreiben) (Fehlverhalten zu sehen im ersten Wireshark) >Der Tipp von dir war richtig :)... >An dem Problem scheiter ich aber leider noch :( Wenn das Problem geloest ist, wird ein weiteres Problem mit dem ephemeral port vakant werden und keine Verbindung moeglich sein, solange das 4er-Tupel im Linux-TCP/IP Stack im TIME_WAIT ("netstat -ant | grep 80 | grep 2345")) ist. >Ich habe einmal anstelle des Connection: close >ein Connection: Keep-Alive probiert. >Nun funktioniert es nach jedem Reset. >& der Server schließt nach einer Zeit die Verbindung automatisch. Wundert mich dass das geht, weil die TCP-Sequenznummern dann nicht stimmen koennen (ist das so eine Art Warm-Reset oder geht das auch mit Strom abklemmen/anschliessen?) Das normale socket-BSD-Interface-API (bei Linux/Windows) sendet bei einem close() automagisch die FIN-Sequenz. Ich orakle mal voraus, dass der jetzige SW-Stand mit stateful-Firewalls zwischendrin (also also klassische nonlocal Internetapplikation) interessante Effekte hervorrufen wird :-) Viele Gruesse, Hans
Bitte 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.