7.e.Q
29-06-2005, 07:15
Hi,
eventuell - ich hoffe, ich trete damit niemandem auf den Schlips - geht meine Frage in dem etwas allgemeiner gehaltenen Topic der Konzeptfrage etwas unter.
Joghurt schlug vor, daß ich bei Überlaufen des Puffers (für Details, siehe anderer Thread) ein ICMP Source Quench an den Absender schicken soll. Da - wenn man so will - ich selbst der Absender bin, muss ich das ICMP Source Quench Paket nur noch aus dem vom Kernel erhaltenen Datenpaket (welches es an den Empfänger zu senden galt, was aber aufgrund des vollen Empfangspuffers auf Empfängerseite nicht möglich war) zusammen bauen.
Jetzt suche ich dafür bereits vorhandene Implementierungen, evtl. Tipps, Hinweise, Hilfestellungen jeder Art, wie ich aus dem Datenpaket, das mein Treiber vom Kernel bekommt ein ICMP Source Quench Paket bauen kann, welches ich postwendend wieder an den Kernel hochreichen kann.
Ich habe mich bei Google schon halb tot gesucht, finde aber leider nicht die für mich passenden Informationen. Der RFC 792 ist für meine Bedürfnisse ein wenig zu abstrakt gehalten, liegt außerdem - wie das bei RFCs ja bekanntlich normal ist - in Englisch vor, was mir die Sache noch weiter erschwert.
Nochmal in Kurzform: ich benötige detailierte Informationen (Schritt für Schritt), wie ich aus dem Datenpuffer (SKB), den der Treiber vom Kernel an seine TX Funktion übergeben bekommt, ein ICMP Source Quench Paket mache, welches ich auf dem regulären Weg (RX Funktion?) wieder zurück an den Kernel geben kann.
Ich will sozusagen den Empfang eines solchen ICMP Source Quench von der Gegenseite simulieren. Simulieren, weil in meinem Fall nicht der Empfänger feststellt, daß seine Puffer voll sind, sondern der Absender, und eben dieser diese Feststellung auch dem Kernel mitteilen soll.
Entschuldigt den Roman und den Doppelpost, aber ich wollte diese Frage nun nochmal separat und klar umrissen in den Raum stellen und hoffe, daß ihr mir da helfen könnt.
Danke
Gruß,
Hendrik
eventuell - ich hoffe, ich trete damit niemandem auf den Schlips - geht meine Frage in dem etwas allgemeiner gehaltenen Topic der Konzeptfrage etwas unter.
Joghurt schlug vor, daß ich bei Überlaufen des Puffers (für Details, siehe anderer Thread) ein ICMP Source Quench an den Absender schicken soll. Da - wenn man so will - ich selbst der Absender bin, muss ich das ICMP Source Quench Paket nur noch aus dem vom Kernel erhaltenen Datenpaket (welches es an den Empfänger zu senden galt, was aber aufgrund des vollen Empfangspuffers auf Empfängerseite nicht möglich war) zusammen bauen.
Jetzt suche ich dafür bereits vorhandene Implementierungen, evtl. Tipps, Hinweise, Hilfestellungen jeder Art, wie ich aus dem Datenpaket, das mein Treiber vom Kernel bekommt ein ICMP Source Quench Paket bauen kann, welches ich postwendend wieder an den Kernel hochreichen kann.
Ich habe mich bei Google schon halb tot gesucht, finde aber leider nicht die für mich passenden Informationen. Der RFC 792 ist für meine Bedürfnisse ein wenig zu abstrakt gehalten, liegt außerdem - wie das bei RFCs ja bekanntlich normal ist - in Englisch vor, was mir die Sache noch weiter erschwert.
Nochmal in Kurzform: ich benötige detailierte Informationen (Schritt für Schritt), wie ich aus dem Datenpuffer (SKB), den der Treiber vom Kernel an seine TX Funktion übergeben bekommt, ein ICMP Source Quench Paket mache, welches ich auf dem regulären Weg (RX Funktion?) wieder zurück an den Kernel geben kann.
Ich will sozusagen den Empfang eines solchen ICMP Source Quench von der Gegenseite simulieren. Simulieren, weil in meinem Fall nicht der Empfänger feststellt, daß seine Puffer voll sind, sondern der Absender, und eben dieser diese Feststellung auch dem Kernel mitteilen soll.
Entschuldigt den Roman und den Doppelpost, aber ich wollte diese Frage nun nochmal separat und klar umrissen in den Raum stellen und hoffe, daß ihr mir da helfen könnt.
Danke
Gruß,
Hendrik