Moin! Ich habe hier ein Problem mit einem AVR Webserver. Der Stack basiert auf dem von Ulrich Radig. Aber um die Details seiner Software sollte hier gar nicht gehen. Sondern eher um die Details des TCP Protokolls. Der Server funktioniert übers LAN bei mir wunderbar. Auch der selbst geschriebene http-Server läuft wunderbar. Das Problem ist, von einer externen IP funktioniert es gar nicht. Die Portweiterleitung im Router funktioniert. Die Pakete kommen am Webserver an und er antwortet darauf. Die Antworten kommen aber scheinbar nicht beim Browser an. Nun hab ich im Debugger beobachtet, dass Pakete mit SYN-Flag beim Webserver ankommen. Daraufhin sendet der Webserver ein Paket mit SYN+ACK zurück. Wenn ich das richtig verstanden habe, sollte dann als nächstes ein ACK Paket ankommen, richtig? Dies kommt aber nicht. Welche Absender-Adresse sollte der Webserver sehen, wenn ein Paket über den Router rein kommt? Die LAN-IP des Routers, meine externe IP, oder die externe IP des Absenders? Bei den am Webserver ankommenden Paketen sehe ich meine externe IP. Der Webserver versucht nun die Antwort an diese Adresse zurück zu senden. Was passiert denn mit einem Paket im LAN, dass nicht zum Subnetz gehört? Nimmt der Router das automatisch an? Oder ist es Sache des Absenders, ein Paket in ein anderes Subnetz an die Adresse des Routers zu senden?
der webserver sieht im Normalfall die Externe IP der Gegenstelle, wenn also die gegenstelle selber hinter einem Router hängt dann siehst du die IP des routers. Aber die wirst NIE die IP deines router sehen. Antworten tut er an die adresse woher das packet stammt. Alles was sicht nicht im Subnetzt befindet wird zum dem default gateway geschickt - was in deinem Fall der router sein müsste. Der route macht genau das gleiche, wenn er das subnetzt nicht kennt schickt er es an seinen default router, was meist ein router deines providers ist. Und so geht es weiter bis das Packet irgendwann man ankommt.
Danke schonmal für deine Antwort. > der webserver sieht im Normalfall die Externe IP der Gegenstelle Gilt dies auch, wenn der Webserver selber hinter einem Router, also im LAN sitzt? > Antworten tut er an die adresse woher das packet stammt. Alles was sicht > nicht im Subnetzt befindet wird zum dem default gateway geschickt Muss der Webserver als Ziel IP denn selber die IP des Defaultgateways eintragen? Oder schickt er das Paket einfach raus, an die externe IP der Gegenstelle und der Router nimmt es automatisch an?
ok, scheint richtig zu sein, dass die externe IP der Gegenstelle in den IP Header eingetragen wird. In den Ethernet-Header kommt dann die MAC-Adresse des Routers. Das Paket wird dann automatisch vom Router angenommen und weitergeleitet. So weit so gut. Was könnte die Ursache sein, dass der Webserver aus dem LAN erreichbar ist, aber von einer externen IP nicht? Hat jemand eine Idee?
Kennt der Webserver eventuell kein Routing? Sprich er schickt das Antwortpaket immer direkt an die IP des Browsers anstatt des Default-Gateways? Was für einen Debugger(?) verwendest Du? Ich würde folgendes Szenario vorschlagen: 1. Browser irgendwo im WAN (mit oder ohne Router, sprich NAT). 2. Router woanders im WAN (Portweiterleitung an Webserver). 3. HUB (kein Switch!) 4. Webserver 5. PC mit Wireshark An den Hub hängst Du deinen Router (2), den Webserver (4) und den PC (5). Nun kannst Du genau mitschneiden, was auf der Leitung liegt. Bitte den PC nichts ans Internet lassen, weil sonst zu viel Müll aufgezeichnet wird. Gerne kannst Du den Mitschnitt hier posten, oder wenn zu lang mir zuschicken (IM zur Kontaktaufnahme).
Jap, auf die Art hab ich nun auch untersucht. Feststellung: der Webserver versucht auf den Verbindungsversuch zu antworten, aber die Pakete verschwinden am Router. Dann hab ich in den Routereinstellungen geblättert, bis mir der MAC-Filter auffiel. Da war die MAC des Servers nicht eingetragen! Nun geht es. in die Tischkante beiß Die Erfahrung lehrt ja, wenn es einen Fehler gibt, der eigentlich nicht da sein dürfte, ist es meistens was total dämliches. Hab ich mir am Anfang meiner Suche auch gedacht, und alle dämlichen Fehler, die mir eingefallen sind, 3 mal überprüft. Hat trotzdem nix genützt ;) Immerhin hab ich jetzt meine Kenntnisse der Detail des TCP/IP Protokolls etwas aufgefrischt, nachdem ich mehrere Stunden Byte für Byte des Netzwerkverkehrs untersucht hab ;)
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.