Abkürzungen ohne Definition. Was ist EP
Hast Du es tatsächlich nicht gefunden? Das ist nämlich (und zwar vor der Benutzung von "EP" als Abkürzung) in #14 im zweiten Absatz schon "erklärt" von mir. Oder es ist doch eine Franchise-Kette für den Vertrieb von Elektro- und Elektronik-Produkten ... wer weiß das schon so genau. Eine weitere Alternative wäre vielleicht "Exo-Planeten" - wobei das dann vermutlich schon wieder deutlich OT wäre.
=========================================================================
wie von sonykatze schon geschrieben hat er es genauso probiert.
Wo steht das in
#1? Davon ist frühestens in #7 nach vielem Hin und Her bei der Beschreibung
eines weiteren Tests die Rede und auch das ist ja nur die Beschreibung eines etwas komplizierteren Verfahrens, auf einem anderen Gerät eine TCP-Verbindung zu starten und dabei zu schauen, wo das SYN-Paket nun bleibt, weil das eben nach seinen Beobachtungen nicht da ankommt, wo er es gerne hätte.
Wenn das von einem anderen Host kommt, als von dem im ausgehenden Tunnel adressierten und dann nicht beim "exposed host" ankommt, ist das sicherlich ein Fehler - da braucht man gar nicht weiter zu diskutieren, das deckt sich auch mit meiner eigenen "Erwartungshaltung". Das war aber gar nicht die Frage (in #1) ... sondern die lautete, wie dieses - aus mancher Sicht wohl nicht nachvollziehbare - Verhalten zustande kommen
könnte und wo man da
irgendetwas einstellen könnte. Und auch wenn ich hier dann selbst von einem "Fehler" spreche/schreibe, ist das absolut meine subjektive Einschätzung ... denn mangels passender Definition ist das dabei zu "erwartende Verhalten" eines Edge-Routers ja gar nicht wirklich festgelegt und auch ein (unterstellter) Standpunkt von AVM, daß dieser Port dann eben für die gesamte Dauer der Existenz der "ausgehenden Verbindung"
für jedes eingehende Paket an einen anderen Host (wozu dann auch der "exposed host" zählen würde) "gesperrt" würde, wäre ja nicht per se "falsch" - sondern eben immer noch Ansichtssache bzw. abhängig von der eigenen Erwartungshaltung, die aber sicherlich auch auf irgendwelchen Erfahrungen (ggf. mit Geräten eines anderen Herstellers) basiert und ja wohl kaum schon bei der Geburt als "Prägung" vorhanden war.
Nur weil ein EP der selbe ist, ist nicht die Verbindung die selbe.
Ich verstehe überhaupt nicht, warum Du mir jetzt - in anderen Worten - genau das noch einmal erklären willst, was ich zuvor bereits selbst geschrieben habe. Wenn es sich bei der eingehenden Verbindung eben um
unterschiedliche EP handelt (dazu reicht es, wenn eine der vier Angaben abweicht), dann SOLLTE das beim "exposed host" aufschlagen, weil es ja gerade nicht auf die ausgehende Verbindung paßt und damit auch keine Antwort innerhalb dieser Verbindung sein kann. Genau das ist aber bei den 1&1-Telefonie-Servern auch der Fall, wenn ich den letzten Absatz in #1 nicht vollkommen mißverstanden habe - die erreichen die öffentliche IP-Adresse der Box auch dann noch auf irgendeinem Port (vermutlich ja auch 5060), wenn von dort bereits eine Verbindung zu irgendeinem anderen Server aufgebaut wurde.
All das, was Du da sonst noch zum "Interesse" des Routers an den vorbeiziehenden Paketen schreibst, ist sicherlich schön und richtig ... gilt aber eben eher für Geräte, bei denen keine Hardware-Beschleunigung vorhanden ist und das alles "im Kernel" bzw. im Connection-Tracking (CT) des Kernels ablaufen kann bzw. muß (und bei CT "interessiert" sich auch der Linux-Kernel dann plötzlich doch wieder für die Flags, weil er dann auch seine "trackings" abräumen muß/kann, wenn die TCP-Verbindung erledigt ist).
BTW: Falls sich jemand hier fragt, warum ich immer von "Kernel" schreibe, obwohl doch ein guter Teil dieser Funktionalitäten bei vielen Distributionen in nachladbaren Modulen steckt (z.B. im "nf_conntrack") ... das sind alles Bestandteile des Kernels in diesem Falle, nur daß sie halt nicht statisch mit diesem gelinkt sind und daher erst dynamisch zur Laufzeit nachgeladen werden können/müssen.
Das ist aber bei einer (modernen) FRITZ!Box mit entsprechendem SoC einigermaßen anders (und bei anderen Routern, die auf diesen SoC basieren, ebenfalls, wenn sie die Patches von Lantiq (oder wie auch immer die gerade heißen mögen) verwenden) - hier besteht nämlich bei einer ausgehenden TCP-Verbindung zusätzlich noch die Aufgabe, die Protocol Processor Engine (PPE) so zu programmieren, daß sie die Pakete durch direkte Manipulationen an ihren Header-Strukturen so umformt, daß diese - und zwar ohne weitere Zuhilfenahme der CPU, bis sich der Status einer Verbindung wieder ändert - direkt weiter an den Client im LAN gesendet werden können.
Und genau deshalb "interessiert" sich das FRITZ!OS auch dafür, wie der genaue Status so einer Verbindung aussieht - dabei erkennt es dann "neue TCP-Verbindungen" eben genau an den gesetzten SYN-Flags in den Paketen und programmiert die PPE auch so, daß alle weiteren Pakete innerhalb dieser Verbindung (wenn sie denn erst mal durch den 3-Way-Handshake erfolgreich aufgebaut wurde) ohne Inanspruchnahme der CPU weitergeleitet werden.
Und aus genau diesem Grund, daß eine TCP-Verbindung auch vom Router als "beendet"
erkannt und dann zeitnah abgeräumt werden kann, macht es auch Sinn, dabei UDP- und TCP-Verbindungen getrennt zu betrachten. Während bei einer ausgehenden TCP-Verbindung der Port nach deren Beendigung auch umgehend wieder "frei" sein sollte (sofern die ganze Geschichte korrekt funktioniert und das tat sie zumindest in früheren FRITZ!OS-Versionen, als ich solche Dinge selbst untersucht habe, tatsächlich), braucht es bei UDP-Verbindungen eben immer das Timeout für diesen Tunnel, also eine gewisse Zeitspanne ohne weiteren Traffic innerhalb dieses Tunnels (das kann man sich auch wieder über das procfs für den AVM-PA ansehen), bevor der "abgeräumt" werden kann.
Erst dann, wenn da wieder (TCP-)Pakete mit gesetzten Flags auftauchen (üblicherweise wären das dann RST und FIN, weil PSH sicherlich auch den Router nicht interessiert, da es keinen Einfluß auch den weiteren Status der Verbindung hat), werden diese zum Client weitergereicht und (i.d.R. zusätzlich, soweit ich weiß bzw. das bisher gesehen hatte) an die CPU übergeben, die dann ihrerseits nach dem kompletten Abbau einer TCP-Verbindung (die ist nun mal nach 2x FIN + ACK am Ende) auch den Eintrag in den PPE-Tabellen entfernen sollte, da ansonsten eben wieder "unsolicited traffic" durch die Firewall käme, wenn der Eintrag weiterhin bestünde und die Daten direkt von der PPE weitergeleitet werden (davon kriegt die CPU dann nicht mal etwas mit, außer ggf. über steigende Zählerstände) - deshalb MUSS die CPU diese Verbindungen auch "überwachen" und die Einträge in der PPE wieder abräumen.
Sollte die PPE dieses "Bereinigen" tatsächlich alleine können (ich weiß es nicht), bliebe ja immer noch die Aufgabe, die innerhalb dieser Verbindung aufgelaufenen "Statistikdaten" (wieviel wurde gesendet, wieviel wurde empfangen) irgendwohin zu sichern - daher würde ich wieder wetten, daß ein "Abräumen" von PPE-Einträgen explizit durch die CPU erfolgt (nur über den "Trigger" dafür könnte man sicherlich diskutieren, weil das ja auch ein von der PPE selbst erkanntes Ende einer TCP-Verbindung sein könnte).
Letztlich landet dann alles das, was von keinem anderen Eintrag in der PPE verarbeitet werden konnte, entweder beim Abdecker und wird von der PPE direkt abgelehnt oder es geht eben an den "exposed host" - wobei es tatsächlich ziemlich schwierig ist, genau auszumachen, was davon dann über die CPU geroutet wird und was nicht (über die CPU ist halt langsamer, auch für die Daten zum "exposed host", der ansonsten ja - quasi als "catch all"-Target - auch direkt angeschrieben werden könnte).
Der einfachste Weg, sich da einen Überblick über den "CPU-Traffic" zu verschaffen (denn ein guter Teil ist eben "closed source" im "kdsldmod.ko" bzw. im Userspace-Daemon "dsld" dazu), ist es tatsächlich, auf der Box selbst einen Paketmitschnitt zu machen ... aber eben nicht mit den Mitteln des FRITZ!OS, weil das dazu ja wieder die Konfiguration der PPE verändert. Dazu braucht man nur ein einzelnes Capture-Programm, z.B. "tcpdump" und mit dem kann man dann das mitschneiden, was "im Normalfall" auch über die CPU läuft. Daß das deutlich weniger ist als der gesamte Traffic, kann man auch hier in diversen Threads (von früher, als das noch nicht so richtig bekannt war) nachlesen - da wunderten sich dann nämlich die Leute, warum in ihren Mitschnitten nur ein Bruchteil der Pakete enthalten war.
Die Tatsache, daß das alles tatsächlich nicht so einfach nachzustellen ist mit einer FRITZ!Box (angefangen bei einem Image mit Shell-Zugang und den notwendigen Tools auf der Box selbst, um das sauber "beobachten" zu können), ist es auch, die mich davon abhält, das jedesmal aufs Neue selbst zu testen - mir reicht es auch, wenn ich die "größeren Zusammenhänge" halbwegs durchschauen kann und wenn meine Erklärungsversuche(!) jemandem nicht passen, muß er sie ja nicht lesen. Wenn sie jemandem nicht einleuchtend erscheinen, diskutiere ich das gerne aus ... wobei ich bei Dir einfach auch keinen Ansatzpunkt für irgendeinen Unterschied in der "Interpretation" sehe - mal abgesehen von Deiner Ansicht, daß es für die Verwaltung von Verbindungen im FRITZ!OS (und in der Folge dann auch in der PPE) total egal wäre, ob es sich um eine TCP- oder eine UDP-Verbindung handelt.
Wenn man sich einen (ungefähren) Eindruck von den Fähigkeiten der PPE verschaffen will, muß man sich - mangels frei zugänglicher Dokumentationen - halt in den Netzwerk-Code des Kernel vertiefen und zwar in den mit den Lantiq-Patches (weil erst da dann die PPE genutzt wird). Ein Teil davon findet sich auch in den AVM-Quellen (unterhalb von drivers/net/avm_cpmac), wobei bei AVM eben große Teile in deren eigenem WAN-Stack stecken und der besteht (nicht ganz scharf "abgegrenzt") in erster Linie aus dem bereits erwähnten "Loadable Kernel Module" (LKM) "kdsldmod.ko" und aus dem - ebenfalls bereits erwähnten - Userspace-Daemon "dsld" für die Konfiguration und die Kommunikation mit dem Rest des Systems.
Daß dabei auch der "Zustand" von Verbindungen überwacht wird, sieht man dann spätestens an entsprechenden Funktionsnamen/-beschreibungen, wie z.B. "ppa_is_tcp_established":
Code:
1318 /*! \brief Returns true if tcp connection state is established for a PPA session.
1319 \param[in] p_session Pointer to ppa connection tracking session data structure.
1320 \return This function returns the one of the following values: \n
1321 - IFX_TRUE if TCP connection state is established after SYN from server. \n
1322 - IFX_FALSE if TCP connection is not established completely. \n
1323 \note
1324 */
1325 int32_t ppa_is_tcp_established(PPA_SESSION *p_session);
, wobei diese Funktion nun gerade wieder ein Beispiel ist, wo AVM den Lantiq-Code tatsächlich durch eigenen ersetzt (denn bei AVM wird diese Lantiq-Funktion dann "ausgeblendet").
Wobei man auch hier wieder sauber zwischen den verschiedenen SoC unterscheiden muß (das oben ist vom VR9) - selbst wenn die Prinzipien bei Lantiq-SoCs halt immer dieselben sind (bzw. neue "Spezialeinheiten" dazukommen), so ist das doch immer vom SoC abhängig und auf anderen Plattformen (z.B. Broadcom-SoCs oder auch die Qualcomm-Linien) werden zwar auch dieselben Prinzipien verwendet, wenn irgendetwas "beschleunigt" werden soll oder muß, aber die Einzelheiten unterscheiden sich dann schon deutlich und das dürfte auch einer der Hauptgründe sein, warum bei AVM vieles erst mal ohne die jeweiligen spezialisierten Hardware-Einheiten umgesetzt wird (quasi basierend auf dem kleinsten gemeinsamen Nenner) und die dann erst nach und nach wirklich "ausgenutzt" werden in späteren OS-Versionen.
