http_get Ulrich Radig

[Hannes H. (hansl_)]

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

[Hans (Gast)]

> 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

[Hannes H. (hansl_)]

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

[STK500-Besitzer (Gast)]

>> 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?

[Hans (Gast)]

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

[Hannes H. (hansl_)]

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

[Hans (Gast)]

>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

[Hannes H. (hansl_)]

Ok vielen Dank :)
kann doch schon morgen testen.

Werde dann meine Ergebnisse posten.

Danke und LG
Hannes

[Simon K. (simon)]

Ein paar TCP/IP Basics wären nicht schlecht...

[Hannes H. (hansl_)]

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

[Hans (Gast)]

> 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!

[Hannes H. (hansl_)]

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

[Hans H. (hanshein)]

>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