Hallo, ich habe klein Webserver gebaut mit Atmega32 und ENC28j60. Soweit funktioniert alles, aber nur mit IExplorer von Windows. Wenn ich versuche AVR Seite mit andere Browser ofnen, zeigt "Keine Seite gefunden". Hat jemand das gleiche Problemm?
Hast du dir schon mal den HTTP-Request und die Antwort mit Wireshark angeschaut?
Ich kann wirklich nur mit IE auf mein Webserver zugreifen. Mit mein IPhone geht auch nicht. Wie kann ich mit Wireshark HTTP-Request anschauen?
Proxy ist ausgeschaltet. Mit Wireshark verstehe ich nicht ganz.
Wireshark ist ein kostenloses Programm, mit dem du dir den gesamten Datenverkehr anschauen kannst, der über die Netzwerkschnittstelle deines PC geht. Es wird zum Beispiel bei der Entwicklung von Netzwerkkomponenten oder zu Ausbildungszwecken eingesetzt. Wie sind denn deine Vorkenntnisse zu Netzwerkprotokollen? Weißt du, wie TCP und HTTP funktionieren? Falls nicht, dann lies dich da man ein Bisschen ein. Sonst wirst du mit den Daten, die Du bei Wireshark mitlesen kannst, nicht viel anfangen können.
Das ist schon klar. Aber welches Unterschied ist zwischen IE und Chrome?
OK, wenn du nicht willst... Jurik schrieb: > Aber welches Unterschied ist zwischen IE und Chrome? IE ist ein Browser von Microsoft. Chrome ist ein Browser von Google. Hilft dir diese Antwort weiter? Nein?
Den Unterschied wirst dann feststellen. Vielleicht ist der Eine etwas grosszuegiger mit einer unvollstaendigen Seite ? Vielleicht fehlt nur ein END-zeichen...
Könnte es sein dass IE Dir augenblicklich Seiten Deines Servers aus dem Cache anzeigt ? Somit wäre der Unterschied zwischen IE und Chrome der, dass IE schonmal auf Deinem Server war (als er funktionierte) und sich Dinge gemerkt hat, die es augenblicklich garnicht mehr abzuholen gibt (weil er kaputt ist).
Also, ich habe 2 x pcap gemacht. ein mal mit IE und einmal mit Chrome. Die beide sind schon unterschiedlich. Wer kann damit was anfangen? PC-IP ist .42 AVR-IP ist .70
Mutti, unmöglich! Weil Server lauft und schaltet auch die Relays ein - aus. Sage, aber nur mit IE
heinzhorst, Dieses Unterschied kenne ich auch, und das das Safari von Mac ist.
Jurik schrieb: > PC-IP ist .42 > AVR-IP ist .70 Also beim IE wird eine korrekte GET Anfrage an den AVR Webserver geschickt und von diesem auch mit dem HTML Dokument beantwortet. Beim Chrom wird gar keine GET Anfrage an den AVR Webserver geschickt (oder du hast sie nicht aufgezeichnet), dafür versucht der AVR Webserver einige fehlerhafte Pakete an den PC zu schicken.
> Die beide sind schon unterschiedlich. Die wesentlichen Unterschiede beginnen damit dass Chrome die Window-Scale-Options mitschickt, der IE nicht. Von da an scheint der AVR kaputte Pakete zu schicken (u.a. mit irrwitzig hohen SEQ/ACK). Kann es sein dass Dein TCP-Stack die Options nicht (richtig(tm)) verarbeiten kann und deswegen durcheinanderkommt? HTH
Was genau steht bei Dir im Navigationsfeld von Chrome ? Was genau steht bei Dir im Navigationsfeld vom IE? das chrome.pcap scheint garkein "GET / HTTP/1.1" zu senden.. nichmal ein "GET". Dann ist der server auch nicht gezwungen vernünftig zu antworten.
Bei Navigationsfeld: Nach Enter drucken: IE: http://192.168.0.70/ Chrome: 192.168.0.70 Und warum Chrome (Safari) schick kein GET?
> das chrome.pcap scheint garkein "GET / HTTP/1.1" zu senden.. nichmal ein > "GET". wie ich schon schrub kommts so weit gar nicht. Aufgedröselt sieht die Kommunikation vereinfacht etwa so aus: Chrome: Mach mal TCP-Verbindung mit Window-Scale-Options AVR: <mmmpfgrpl> Chrome versteht nur Bahnhof, wartet kurz.. Chrome: Mach mal TCP-Verbindung mit Window-Scale-Options AVR: <mmmpfgrpl> Chrome versteht nur Bahnhof, wartet etwas länger.. Chrome: Mach mal TCP-Verbindung mit Window-Scale-Options AVR: <mmmpfgrpl> .. Chrome stellt fest dass das Gegenüber nicht will^Wkann und bricht ab. Nix für ungut.
> Chrome: Mach mal TCP-Verbindung mit Window-Scale-Options > AVR: <mmmpfgrpl> > Chrome versteht nur Bahnhof, wartet kurz.. > Chrome: Mach mal TCP-Verbindung mit Window-Scale-Options > AVR: <mmmpfgrpl> > Chrome versteht nur Bahnhof, wartet etwas länger.. > Chrome: Mach mal TCP-Verbindung mit Window-Scale-Options > AVR: <mmmpfgrpl> Kenne micht zwar nicht aus mit dem NetIO, aber könnte es sein, dass der verwendete TCP/IP-Stack nicht normgerecht ist, sondern nur rundimentär?
So, hab mir mal deinen PCAP-Files genauer angesehen. Beim SYN ACK-Paket 3-Way Handshake von TCP ist der TCP-Header falsch. Genauer: Die Header-Länge (HLEN) stimmt nicht. In deinem PCAP-File steht da 0x80. Das ist die Länge in Bytes. Dort müsste aber die Länge in 32-Bit Wörtern stehen. Das wäre dann 0x20. Ich würde sagen, derjenige, der den TCP-Stack geschrieben hat, hat Mist gemacht und eine RFC nicht richtig interpretiert. Dass die Seite im einem anderen Browser angezeit wird, könnte daran liegen, dass dieser fehlertolleranter ist. Im das zu beheben müsstest du etwas tiefer in den Quellcode des TCP-Stacks eintauchen. Welchen Stack verwendest du denn?
Nachtrag: Das gilt nicht nur für den Handshake, sondern für alle TCP-Pakete, die vom AVR gesendet werden.
Korrektur: > Genauer: Die Header-Länge (HLEN) stimmt nicht. In deinem PCAP-File steht > da 0x80. Jepp. > Das ist die Länge in Bytes. Nope, das ist die Länge in 32-Bit-Wörtern. 8 *32Bit == 32 Bytes. Passt. > Dort müsste aber die Länge in 32-Bit Wörtern stehen. Tut sie. > Das wäre dann 0x20. Nope. 0x20 wären 2 32-Bit-Wörter (und das wäre laut Speck zu kurz, die verlangt afair mindestens 5 32-Bit-Wörter). > Dass die Seite im einem anderen Browser angezeit wird, könnte daran > liegen, dass dieser fehlertolleranter ist. Nope, das liegt daran dass beim Chrome (bzw. dem darunterliegenden TCP-Stack) erst gar keine Verbindung zustande kommt, bei der Konkurrenz (bzw. dessen TCP-Stack) aber schon. > Ich würde sagen, derjenige, der den TCP-Stack geschrieben hat, hat Mist > gemacht Das vermute ich auch. Laufen der Chrome und der IE eigentlich auf der selben Plattform? HTH und nix für ungut.
g457 schrieb: > Nope, das ist die Länge in 32-Bit-Wörtern. 8 *32Bit == 32 Bytes. Passt. Hast Recht. Ist mir auch gerade aufgefallen, dass HLEN nur aus dem oberen Nibble besteht.
>ich habe klein Webserver gebaut mit Atmega32 und ENC28j60. Welchen? >der Chrome und der IE laufen auf gleiche rechner Was sagt Firefox dazu;)
Blöde Frage: Um welchen TCP/IP-Stack handelt es sich eigentlich ? Ist es der originale vom NetIO, oder OpenMCP, oder der von Ulrich Radig? Das wurde im ganzen Thread nicht wirklich genannt.
Wahrscheinlich selbst ein paar Zeilen mit wenig Ahnung zusammengekloppt...
Dekad Oschi schrieb: > Wahrscheinlich selbst ein paar Zeilen mit wenig Ahnung > > zusammengekloppt... Wohl kaum. Nun sei nicht gleich so negativ. Btw.: Hast du schon mal einen TCP-Stack geschrieben? Benutzt? Nein? Dachte ich mir.
>Wohl kaum. Nun sei nicht gleich so negativ. Btw.: Hast du schon mal einen TCP-Stack geschrieben? Benutzt? Nein? Dachte ich mir. Ich hab einen Webserver fuer einen AVR ohne Stack geschrieben...
TCP Stack aleine zu schreiben ist fast wie Selbsmord!! Keine Annung von wem der Stack ist, aber ihr habt recht! Es lag an Kopflänge!!! IE sendet Header mit 62 Byte, aber Chrome sendet Header mit 66 Byte. Im Stack wurde 62 Byte fest! Ich habe auf 66 Byte geändert. Jetzt geht mit Chrome und mit IE einwandfrei. DANKE für Tip!!!! Ihr seit SUPER!!! Jetzt suche ich weiter, warum Safari von IPhone geht nicht. ich habe festgestellt, das AVR antwortet auf Reply nicht. IE senden wieder Header mit 42 Byte, Safari mit 60.
> Im Stack wurde 62 Byte fest!
Das ist extrem pöse. Auch wenn man auf vieles verzichen kann (bzw. muss)
auf einem 8bitter, die Headerlänge prüfen ist absolut unvermeidbar - wie
man sieht :-) Am besten gleich mal einen Käferbericht filen.
HTH
>Keine Annung von wem der Stack ist, aber ihr habt recht!
Zeig doch mal den Code, dann finden wir das ganz schnell raus;)
Dekad Oschi schrieb: > Ich hab einen Webserver fuer einen AVR ohne Stack geschrieben... Autsch! Wollte mich gerade fachlich mit dir duellieren. Aber wie ich sehe, bist du unbewaffnet.
Das commt von PC: FF FF FF FF FF FF 40 A6 D9 80 49 10 08 06 00 01 08 00 06 04 00 01 40 A6 D9 80 49 10 C0 A8 00 19 00 00 00 00 00 00 C0 A8 00 46 00 00 00 00 00 00 00 00 00 00 DD 09 00 10 66 7A FD C3 Das commt von Safari: FF FF FF FF FF FF 40 A6 D9 80 49 10 08 06 00 01 08 00 06 04 00 01 40 A6 D9 80 49 10 C0 A8 00 19 00 00 00 00 00 00 C0 A8 00 46 00 00 00 00 00 00 00 00 00 00 DD 09 00 10 66 7A FD C3
Korigire: Von PC: FF FF FF FF FF FF 00 0E A6 70 1D 0F 08 06 00 01 08 00 06 04 00 01 00 0E A6 70 1D 0F C0 A8 00 02 00 00 00 00 00 00 C0 A8 00 46 Eben nur 42 byte
>Zeig doch mal den Code, dann finden wir das ganz schnell raus;) >Achtung Bascom! Da hab ich den Mund wohl zu voll genommen;) Und tschüß.
>Autor: heinzhorst (Gast) >>Dekad Oschi schrieb: >> Ich hab einen Webserver fuer einen AVR ohne Stack geschrieben... >> >Autsch! Wollte mich gerade fachlich mit dir duellieren. Aber wie ich >sehe, bist du unbewaffnet. Ich weiss zumindest genau wie so ein Packet ausieht, wie ein HTTP-Get aussieht und wie die Reply aussehen muss. Es gibt Stellen, da muessen 2 * CR+LF hin. Und ich hab'n Bootloader geschrieben, der konnte ab einem Server laden.
@Jurik >TCP Stack aleine zu schreiben ist fast wie Selbsmord!! >Keine Annung von wem der Stack ist, aber ihr habt recht! Steht doch im Code :-) >FF FF FF FF FF FF 00 0E A6 70 1D 0F 08 06 00 01 08 00 06 04 00 01 00 0E >A6 70 1D 0F C0 A8 00 02 00 00 00 00 00 00 C0 A8 00 46 Das scheint nur ein ARP-Request zu sein. Vielleicht probierst du mal eine andere Software z.B. die vom ethersex-Projekt. Volker
Dekad Oschi schrieb: >>Autor: heinzhorst (Gast) >>>Dekad Oschi schrieb: >>> Ich hab einen Webserver fuer einen AVR ohne Stack geschrieben... >>> >>Autsch! Wollte mich gerade fachlich mit dir duellieren. Aber wie ich >>sehe, bist du unbewaffnet. > > Ich weiss zumindest genau wie so ein Packet ausieht, wie ein HTTP-Get > aussieht und wie die Reply aussehen muss. Es gibt Stellen, da muessen 2 > * CR+LF hin. Und ich hab'n Bootloader geschrieben, der konnte ab einem > Server laden. Dann hast du wohl eher einen HTTP-Client geschrieben. Einen HTTP-Server ohne Stack zu schreiben ist meiner Meinung nach unsinnig. Da hat man dann nicht mal TCP-Sessions (also nur eine Verbindung gleichzeitig) oder TCP-Retransmissions bei Fehlern.
Nee. Es war ein Server auch wenn der Bootloader auf einen Server zugreift. Der Benutzer sah immer die Webseite des Devices auf seinem PC. Die Kommunikation war nicht ueber TCP/IP, sondern uber serial. Sessions gab's auch nicht, nur eine zustandslose resp verbindungslose Kommunikation. Dann gibt's auch nur einen Client aufs Mal der was will.
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.