UDP Paket-Größe ermitteln

[NerdIII]

Kennt jemand das Spiel Half-Life? Das läuft ja über UDP. Früher konnte man Serverinformationen einfach abfragen, da man ein UDP-Paket fester größe vom Server bekam, aber mittlerweile ist die größe der Antwort variabel (was ja durchaus Sinn macht).
Mein Problem ist jetzt, die richtige Puffergröße zu finden. Klar könnte ich einfach mal den Puffer auf 100 kb festlegen, aber warscheinlich ist das kein guter Stil und nicht lehrreich *g*.
Mit ioctlsocket(socket, FIONREAD, &size) in einer Schleife bis 'size' > 0 bekomme ich zumindest einen passenden Wert wenn ein Paket ankommt.
Meine Frage:
Wie ermittelt man 'offiziell' die Größe eines ankommenden Pakets?

[TGGC]

Grösse sollte doch im Header das Pakets stehen.


Bye, TGGC

[NerdIII]

Ok, danke. Jetzt weiss ich, dass im Header Client- & Serverport sowie Länge und eine 16-bit Prüfsumme stehen. :)
Aber muss ich unter Windows dafür extra ein RAW-Socket erstellen oder komme ich an den Header auch mit einem gewöhnlichen Datagram-Socket?

[TGGC]

Fazu solltest du einfach mal die Doku der API lesen, die du verwendest.


Bye, TGGC

[NerdIII]

Die API ist von Microsoft (WinSock) und das einzige was da bei recvfrom steht, ist dass ein Fehler auftritt, wenn der Puffer für die Daten nicht gross genug ist. :D
Kein Sterbenswörtchen darüber wie ich die größe ermitteln könnte. Die meisten Tutorials senden auch nur Testdaten mit fixer Größe oder 256 Bytes, damit es nicht zu komplex wird.
Und so habe ich halt gehofft dass jemand anderes hier im Forum das schon mal gemacht hat. Ansonsten würde mir auch der source code von irgendeiner UDP Software helfen, die unterschiedlich große Pakete empfangen muss.

[TGGC]

Nana, da steht schon ein bissl mehr, man muss es halt nur Lesen:

Return Values
If no error occurs, recvfrom returns the number of bytes received.

[...]

For message-oriented sockets, data is extracted from the first enqueued message, up to the size of the buffer specified. If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recvfrom generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost.

If the from parameter is nonzero and the socket is not connection oriented, (type SOCK_DGRAM for example), the network address of the peer that sent the data is copied to the corresponding sockaddr structure. The value pointed to by fromlen is initialized to the size of this structure and is modified, on return, to indicate the actual size of the address stored in the sockaddr structure.

Quelle: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/recvfrom_2.asp


Bye, TGGC

[NerdIII]

Hey, moment, dass ist nicht fair! Klar gibt mir das die größe dessen was ich gelesen habe. Aber BEVOR ich lese brauche ich doch die Größe, um den Puffer anzulegen. ;)
Aber halb so wild, ich hab mir jetzt einen 64kb Puffer angelegt und in den passt praktisch alles rein. Nur wenn jetzt ein Hacker daher kommt und mir ein 70 kb großes Paket schickt - falls möglich durch Fragmentierung, dann gibt es die üblichen Programmabstürze.
Ich hab auch versucht einfach mal 256 Bytes zu lesen und den Rest danach, aber das funktioniert nicht - das Paket wird nach recvfrom komplett gelöscht.

[bloodriver]

Hey, moment, dass ist nicht fair! Klar gibt mir das die größe dessen was ich gelesen habe. Aber BEVOR ich lese brauche ich doch die Größe, um den Puffer anzulegen. ;)
Aber halb so wild, ich hab mir jetzt einen 64kb Puffer angelegt und in den passt praktisch alles rein. Nur wenn jetzt ein Hacker daher kommt und mir ein 70 kb großes Paket schickt - falls möglich durch Fragmentierung, dann gibt es die üblichen Programmabstürze.
Ich hab auch versucht einfach mal 256 Bytes zu lesen und den Rest danach, aber das funktioniert nicht - das Paket wird nach recvfrom komplett gelöscht.

öhm ma ne frage... wozu brauchstn du das? willste server-daten abfragen oder wie?

[TGGC]

Nur wenn jetzt ein Hacker daher kommt und mir ein 70 kb großes Paket schickt - falls möglich durch Fragmentierung, dann gibt es die üblichen Programmabstürze.Wieso fängst du die Abstürze nicht ab?

Oder wie wäre Lesen?

MSG_PEEK Peeks at the incoming data. The data is copied into the buffer but is not removed from the input queue. The function subsequently returns the amount of data that can be read in a single call to the recvfrom (or recv) function, which may not be the same as the total amount of data queued on the socket. The amount of data that can actually be read in a single call to the recvfrom (or recv) function is limited to the data size written in the send or sendto function call.


Bye, TGGC

[NerdIII]

@bloodriver: Du hörst dich an wie ein blutige-ballerspiele-spieler. Das passt gut. Ja, ich will allgemeine Server-Infos abfragen und die kommen in Paketen unbekannter Größe.

@TGGC: Glaub mir, ich hab das alles gelesen. Der Punkt ist doch, dass ich - und jetzt noch mal in Stichworten:
1. warten möchte auf ein Paket
2. wissen möchte wie groß es ist
3. den passenden Puffer anlegen und das Paket einlesen
und da hilft auch kein MSG_PEEK. Wenn ich nämlich einen Puffer der Größe 1 angebe wird die Funktion mir einfach den Fehler 'Puffer zu klein' zurückgeben statt die nötige Größe (wie bei einigen anderen Funktionen möglich).

Ich poste mal einen Link zu den Serveranfragen:
http://www.valve-erc.com/srcsdk/Code/Networking/serverqueries.html

Aber das kann ja andererseits auch nicht wirklich kompliziert sein, oder? ;)

[Jan Krüger]

Der Punkt ist doch, dass ich - und jetzt noch mal in Stichworten:
1. warten möchte auf ein Paket
2. wissen möchte wie groß es ist
3. den passenden Puffer anlegen und das Paket einlesen
Wenn du den Puffer bei jedem Lesen eines Paketes dynamisch anlegst oder veränderst, wird dein Programm zwar ein ganz kleines bisschen weniger speicherintensiv, aber dafür bedeutend rechenzeitintensiver. Ich rate von solchen Dingen ab.

[NerdIII]

Wenn du den Puffer bei jedem Lesen eines Paketes dynamisch anlegst oder veränderst, wird dein Programm zwar ein ganz kleines bisschen weniger speicherintensiv, aber dafür bedeutend rechenzeitintensiver. Ich rate von solchen Dingen ab.

Ok, danke. Hast wohl recht. Trotzdem muss ich dem Puffer nun irgendeine Größe geben. Gibt es da ein sicheres Minimum? Kann z.B. kein Paket größer als 64KB werden? (Ich weiss nicht wie es mit Fragmentierung aussieht.)

[bloodriver]

@bloodriver: Du hörst dich an wie ein blutige-ballerspiele-spieler. Das passt gut. Ja, ich will allgemeine Server-Infos abfragen und die kommen in Paketen unbekannter Größe.

lol? :D

ne ich zock eigentlich nur cs 1.6, ut und wc3. sonst grad mafia @ singeplayer :>

hab im anhang mal ne kleine text-datei... vielleicht hilft die dir weiter. is aus dem sdk ( neuestes glaub ich )

[Jan Krüger]

Ok, danke. Hast wohl recht. Trotzdem muss ich dem Puffer nun irgendeine Größe geben. Gibt es da ein sicheres Minimum? Kann z.B. kein Paket größer als 64KB werden? (Ich weiss nicht wie es mit Fragmentierung aussieht.)
Nein, kann es nicht. Die Länge ist im UDP-Paketheader in nur 16 Bits angegeben. Das gilt nicht für UDP/IPv6-Jumbograms (RFC 2147).

[bloodriver]

The packet should start with 4 consecutive bytes of 255 (32-bit integer -1) and the string...

To issue the actual rcon, the remote App then responds with a UDP packet containing 4 255s and

Messages are sent to the server by sending 4 consecutive bytes of 255 (32-bit integer -1) and then the string command followed by a zero byte to terminate it

...
"players"
Server responds with the following packet:
(int32) -1
(byte) ASCII 'D' (players response, S2A_PLAYER)
(byte) active client count

for each active client
(byte) client number / index
(string) player name
(int32) client's frag total
(float32) client's total time in-game
...



ich wär dafür... anzahl der player * größe der infos ( wenn man das irgendwie rausbekommt. dann bei den regeln das gleiche )

[NerdIII]

@bloodriver: danke fürs Nachschlagen, aber das aktuelle Protokoll hab ich doch schon in nem Link gepostet.
Ich glaube ich geh einfach mal davon aus, dass 64KB ausreichen. Es ist ja das alte IP-Protokoll.
Jumbograms? Lol, und ich dachte die RFCs seien total trocken und langweilig.

[Jan Krüger]

Du solltest mal die jeweiligen RFCs vom 1. April lesen.

[Xpyder]

Ob der Pufferspeicher ausreicht, hängt weniger von den
Paketgrößen ab, als vielmehr davon, wie schnell Du die
Daten verarbeiten kannst, bevor neue Daten kommen.

Ein IP-Paket kann (mit Header) gar nicht größer als
64kByte werden - nicht mal dann, wenn es fragmentiert ist
- denn die Fragmentierung ist nur für max. 64kByte Pakete
ausgelegt. Genauer gesagt, wird ein IP-Paket maximal
64Kbyte minus 1.

Es ist natürlich so, daß es den theoretischen Fall gibt,
daß ein Paket wirklich mal 64kByte groß ist. Das müßtest
Du dann quasi in "Nullzeit" verarbeiten, bevor das nächste
Byte des neuen Pakets das alte im Puffer überschreibt...
Diesen Umstand kann man aber dadurch beheben, indem man
schon vorher maximale Paketgrößen in den vorherigen
"Sub-Protokollen" festlegt.

Desweiteren: Netzwerk-Pakete sind maximal 1500 Bytes groß
(ohne Netzwerk-Header, der aber auch nur 16 Bytes oder
sowas ist). Das ist halt ein Standard, der sich damals
"konstruktionsbedingt" (also weil der NE-2000-Chip, der
damals auf jeder Netzwerkkarte war, das so gemacht hat)
durchgesetzt hat und eigentlich auch heute noch gilt. -
D.h. erwarte aus nem normalen Netzwark keine Pakete mit
über 1500 Bytes Daten...

UDP ist zwar nicht exklusiv auf IP festgelegt - aber
meines Wissens gibts keine andere gebräuchliche
Implementation, die UDP benutzt - so daß UDP also immer
zusammen mit IP auftritt. Die Größe des IP-Headers steht
in den unteren 4 Bit des ersten Bytes des Headers und muß
mit 4 multipliziert werden (der Header ist immer ein
Vielfaches von 4 lang). Er ist mindestens 20 und höchstens
60 Bytes groß. Danach folgt der UDP Header, der immer 8
Bytes groß ist. An der Stelle 6 (vom Anfang des
UDP-Headers aus) steht die Größe des UDP-Pakets (als Word)
plus Header, davon ist also 8 abzuziehen.
Und auch, wenn ich Dir jetzt nix neues erzähle:
Inernetdaten werden - im Gegensatz zur auf dem PC üblichen
Anordnung (vom kleinsten zum größten Byte) mit dem größten
Byte zuerst gespeichert.
Eventuell vorhandene Restdaten des UDP sind als Schrott
anzusehen - sie sind meistens, wenn vorhanden, sogenanntes
"Padding", d.h. sie füllen das Paket auf.
(Netzwerkpakete müssen meines WIssens mindestens 64 Byte
groß sein....)

Entschuldige, falls ich lediglich genervt habe. Wenn ja:
Vielleicht hilfts ja jemand anderem...

[Felix Kaiser]

Also halten wir fest: UDP transport maximal 65527 Bytes per Datagram, am besten geeignet ist ein statischer Puffer mit dieser Größe, in dem das Datagram empfangen wird, dann haben wir das komplette Datagram, dessen Größe und können damit arbeiten, es bei Bedarf in einen kleineren Puffer kopieren, damit im Hauptpuffer wieder Platz ist.

[Xpyder]

UDP transport maximal 65527 Bytes per Datagram...
Kommt drauf an, welchen "Träger" es benutzt. Meines Wissens
gibts keine andere gebräuchliche Kombination außer die mit
IP (derselbe, der auch bei TCP benutzt wird).
Der IP-Header braucht mindestens 20 Bytes, was die Maximalgröße
der reinen Daten auf 65507 beschränkt. (Da ist dann der
UDP-Head, der die Größe enthält, aber nicht enthalten!)
Im Gegensatz zu TCP wird bei UDP die Größe der Daten
mitgespeichert - will sagen: Es entspräche sogar noch dem
Standard, wenn am Ende des UDP-Pakets ein paar "Müll-Daten"
wären, die dann zu ignorieren wären. (Sowas macht aber meines
wissens keiner - außer vielleicht ein paar satanistischer
Metalbands, um darin geheime Botschaften zu verstecken...)

am besten geeignet ist ein statischer Puffer mit dieser Größe,...
Imo am besten geeignet sind mindestens zwei solcher Puffer,
denn nur weil das Paket da ist und man es kurz bearbeiten
will, wartet "drüben" ja keiner mit dem Daten-Senden.
Will sagen: ein knapp 64kB-Puffer plus X - wobei X wie
Anzahl zu erwartender Daten sind, die höchstens während
der Zeit ankommen, in der man dieses Paket bearbeitet.
Ich persönlich empfehle zum Empfangen serieller Daten immer
einen Ringpuffer. (Falls wider Erwarten nicht bekannt, wie
sowas funzt, fragen. Im Prinzip wie z.B. der Tastaturpuffer.)
Das hat auch den Vorteil, daß man sich das Umkopieren
sparen kann. (Man wird die Daten sowieso nochmal irgendwann
kopieren - nämlich (klar) für jeden UDP-Port natürlich
woanders hin. (Man will sie ja kaum "gemischt" haben.) -
Oder man empfängt/sendet eh nur auf einem "Socket" - dann
kann man natürlich alle Pakete, die nicht "passen", von
vornherein ignorieren.

[Felix Kaiser]

Da die Größe eines IP-Pakets sich am MTU-Wert der Schnittstelle orientiert, über das es gesendet wird, sind problemlos Pakete mit genau 64kB über IP dank Fragmentierung möglich, theoretisch sogar etwas darüber. Da aber der UDPHeader ein Längenword hat, das die Größe angibt, der höchstmögliche Wert 65535 Bytes ist, da aber der UDP-Header mitgerechnet wird, kann ein UDP-Paket maximal 65527 Bytes Daten transportieren. Mehr erlaubt UDP nicht.

[Pukys]

Hey, moment, dass ist nicht fair! Klar gibt mir das die größe dessen was ich gelesen habe. Aber BEVOR ich lese brauche ich doch die Größe, um den Puffer anzulegen. ;)
Aber halb so wild, ich hab mir jetzt einen 64kb Puffer angelegt und in den passt praktisch alles rein. Nur wenn jetzt ein Hacker daher kommt und mir ein 70 kb großes Paket schickt - falls möglich durch Fragmentierung, dann gibt es die üblichen Programmabstürze.
Ich hab auch versucht einfach mal 256 Bytes zu lesen und den Rest danach, aber das funktioniert nicht - das Paket wird nach recvfrom komplett gelöscht.

Diese Blöcke sollte dir inzwisschen das Betriebssystem herausfischen. Der PoD-Angriff funktioniert sogar bei Windows nicht mehr. Also kann das Paket maximal 64kb groß werden. Und wenn du ganz sicher gehen willst, legst du dir einen Buffer von 64kb+4kb an. Mir ist kein Netzwerkprotokoll mit einer Paketlänge über 4kb bekannt.

Der saubere Weg geht über ioctlsocket, wie du schon angesprochen hast. Das ist der "offizielle" Weg, der "große-Puffer-Trick" ist die Quick'n'Dirty-Methode. Und recvfrom kann eigentlich auch "halbe" Pakete lesen, der Rest verbleibt dann halt im Puffer.

[Xpyder]

Komisch - ich dacht immer, die Angabe bei "Size" im
IP-Header gilt für die Größe des unfragmentierten
Gesamtpakets (plus einem IP-Header).
Und die ist ja wohl max. $FFFF.
Problem wäre, wenn jemand ein Fragment schickt, das a) an
Position $FFF8 liegt und b) selber größer ist als 7 Bytes.
Aber normalerweise sollte eine VERNÜNFTIGE Implementation
von IP dieses dann als das behandeln, was es ist: Nämlich
als Datenmüll.
Bestenfalls könnte man die ersten 7 Bytes benutzen - aber
eigentlich würd ich ehrlich gesagt so'n Paket wegschmeißen.

Jetzt mal im Ernst: DAS ist ein "HACKER-TRICK"?? Gibts
ehrlich Programme (IP-Implementationen), die man mit so'nem
Blödsinn aus Kreuz legen kann? (Die dann quasi das Paket
"über den Rand" vollschreiben und irgendwelche wichtigen
Daten dabei überschreiben...?) Das ist ja wirklich armselig...
(Wenn man bedenkt, wie alt der IP-Standard schon ist...)

[Felix Kaiser]

Bei einem MTU-Wert von 1500 kann ein IP-Paket maximal 1480 Bytes Daten transportieren. Und nur das Paket mit dem Fragment-Offset 0 transportiert den Header des IP-Protokolls, das durch das IP-Paket übertragen wird. Somit bekommt man mit dem ersten Paket schon den UDP-Header, darin steht die Gesamtgröße des UDP-Pakets, die nicht größer als 65535 Bytes sein kann einschließlich des UDP-Headers. Meine Implementierung handhabt es so grundsätzlich Fragmentierung der weiteren Protokollimplementierung zu überlassen, wie UDP oder ICMP. Bei TCP sollte man keine Fragmentierung verwenden, man hat stattdessen die Möglichkeit über eine TCP Option die maximale Größe eines TCP Segments anzugeben, bei einem MTU Wert von 1500 sind das 1460 Bytes. Bei ICMP verzichte ich großzügigerweise auf Fragmentierung. Und bei UDP ist das ganz leicht. Ein paar strenge Längenprüfungen in der IP-Implementierung reichen um ungültigen Quatsch zu verwerfen und somit kann kein Datagramm mehr als 65527 Bytes Daten transportieren.

[Pukys]

Ein IP-Paket kann (mit Header) gar nicht größer als
64kByte werden - nicht mal dann, wenn es fragmentiert ist
- denn die Fragmentierung ist nur für max. 64kByte Pakete
ausgelegt. Genauer gesagt, wird ein IP-Paket maximal
64Kbyte minus 1.

Der Fragment-Headereintrag bestimmt den Anfangsoffset eines Fragments im Paket. Ein Paket kann so theoretisch über 64KB groß werden ( z.B. Fragment-Offset = 0xFFF0 und Paketlänge 1500 = 64KB + 1484 Bytes!), was auch für die berühmten PoD-Attacken benutzt wurde.

Desweiteren: Netzwerk-Pakete sind maximal 1500 Bytes groß
(ohne Netzwerk-Header, der aber auch nur 16 Bytes oder
sowas ist). Das ist halt ein Standard, der sich damals
"konstruktionsbedingt" (also weil der NE-2000-Chip, der
damals auf jeder Netzwerkkarte war, das so gemacht hat)
durchgesetzt hat und eigentlich auch heute noch gilt. -
D.h. erwarte aus nem normalen Netzwark keine Pakete mit
über 1500 Bytes Daten...

Nein. Im ETHERNET dürfen Pakete maximal 1536 Bytes groß werden (zuzüglich der Header), aus physikalischen Gründen (genauer: Weil die Busytime des Ethernetkabels bei 10MBit zuzüglich Interframe-Gap und Preamble maximal 64µs betragen darf (bei einem 205m langem Kabel) - Mit Verweis auf ITU/IEEE 802.1).
Bei anderen Netzwerken sieht es anders auch, z.B. bei WLAN darf ein Paket 2564 Bytes lang werden, bei Big Packets auf knapp über 4KB. Bluetooth und CAPI sehen andere Paketgrößen vor, sie dürfen dort ausgehandelt werden, da diese Protokolle nur bedingt als Blockprotokolle gelten dürfen.

UDP ist zwar nicht exklusiv auf IP festgelegt - aber
meines Wissens gibts keine andere gebräuchliche
Implementation, die UDP benutzt - so daß UDP also immer
zusammen mit IP auftritt.

UDP *ist* das ETSI-konforme "connection less" (CL)-Protokoll es IP-Stacks. Viele andere lehnen Übertragungssysteme lehnen sich an UDP an, aber in erster Linie, weil UDP eh schon sehr stark an HDLC erinnert, das von der ETSI und der ITU als Level2-Carrierprotokoll bevorzugt wird. Die anderen CL-Protokolle sehen oft ähnlich wie UDP aus, sind aber strenggenommen HDLC-Derivate, auch wenn die W3C und das IP steering comitee immer gern UDP als die Mutter aller Protokolle hinstellt.

[Pukys]

Du solltest mal die jeweiligen RFCs vom 1. April lesen.

Du meinst z.B. "IP over avian carriers"?

[Pukys]

Komisch - ich dacht immer, die Angabe bei "Size" im
IP-Header gilt für die Größe des unfragmentierten
Gesamtpakets (plus einem IP-Header).
Und die ist ja wohl max. $FFFF.

Stimmt. Der Eintrag size (16Bit) gibt die komplette Größe des Datagrammpaketes an. Aber es gibt ja noch das Feld Fragment-Offset an Bit-Offset 51: Fragment-Offset. Damit kann man dumme Spielchen machen.

Problem wäre, wenn jemand ein Fragment schickt, das a) an Position $FFF8 liegt und b) selber größer ist als 7 Bytes.

Dann hast du einen klassischen boundary error. :-)


Aber normalerweise sollte eine VERNÜNFTIGE Implementation
von IP dieses dann als das behandeln, was es ist: Nämlich
als Datenmüll.
Bestenfalls könnte man die ersten 7 Bytes benutzen - aber
eigentlich würd ich ehrlich gesagt so'n Paket wegschmeißen.

Da hast du vollkommen recht.
Aber ehrlich: Das IP-Protokoll stammt aus einer anderen Zeit. Das IP-Protokoll ist ein universitärer Spinoff eines militärischen Thinktank-Spielballs: Es war als einfacher und schneller Interconnect-Hack zwischen den Universitäten oder zwischen den einzelnen Rechnern gedacht, am Aufbau erkennt man, das es primär nicht mal aufs Routing ausgerichtet ist!
Damals hat man nicht mit bösen Attacken gerechnet, dafür gab die militärischen Protokolle, sondern es war als einfaches Kommunikationsprotokoll gedacht.
Daher arbeiteten viele Stacks nach dem graceful accept Prinzip: Wenn die Cecksumme und die Adressen stimmen, wird der Paketheader komplett stimmen; Immerhin weiß die andere Seite ja, was sie tut. Wie gesagt: Universitäres Umfeld, kein Real-Life-Umfeld!

Jetzt mal im Ernst: DAS ist ein "HACKER-TRICK"?? Gibts
ehrlich Programme (IP-Implementationen), die man mit so'nem
Blödsinn aus Kreuz legen kann? (Die dann quasi das Paket
"über den Rand" vollschreiben und irgendwelche wichtigen
Daten dabei überschreiben...?) Das ist ja wirklich armselig...
(Wenn man bedenkt, wie alt der IP-Standard schon ist...)

Klar. Es war neben Smurf der erste größere Exploit des IP-Protokolls.
Und du kannst dir nicht vorstellen, wieviele Stacks anfällig waren:

Es waren nämlich fast alle.

Wie gesagt, es herrschte allgemein die "graceful accept"-Mentalität vor, man hat gar nicht mit dieser Art von böswillig misgeformten Paketen gerechnet. Und Rechenzeit (und vor allem Speicher) war teuer, also optimiert man jeden sanity check heraus, den man nicht unbedingt braucht.

Anfällige Stacks waren u.a.: Die ersten BSD-Implementationen, die ersten Linux-Implementationen, damit auch trumpet, Windows 95....

Die meisten Stacks sind inzwischen sicher, aber bis weit ins neue Jahrtausend waren (und sind) noch viele embedded Stacks anfällig! Und das bei einem Exploit, der im Grunde genommen seit den späten 70ern bekannt ist!

Anmerkung: Meist betrifft es nicht mal die TCP oder UDP-Protokollhandler, die anfällig sind. Meist ist es das ICMP-Protokoll, das wird nämlich meistens "seitlich" aus dem UDP-Stack herausgezogen. Der berühmte Ping of Death basiert auf genau diesem Pufferüberlauf!

Ein anderer beliebter "Scherz" um speziell Router aus dem Tritt zu bringen, besteht darin, den Router mit fragmentierten Paketen zu überhäufen und das "Dont Fragment"-Flag zu setzen. Die Router müssen dann nämlich die Pakete zwischenspeichern, und viele Router bekommen ein Speicherproblem, bevor sie die Pakete wegen eines Timeouts wegwerden! Eine kleine, miese Abart des gleichen Tricks, um speziell Router "abzuhängen".

[NerdIII]

Hey ich danke euch allen für die Antworten und den kleinen Einblick in die Entstehung des IP-Protokolls. Ich werde jetzt einfach mit der festen Puffergröße arbeiten. Pakete von 64 KB wird wohl sowieso kein HL-Server senden und Sicherheitsabfragen gegen Übeltäter baue ich jetzt auch ein. Besser man fängt gleich damit an. :)

[Grober]

Vielleicht hilft auch getsockopt mit SO_MAX_MSG_SIZE?

[Pukys]

Vielleicht hilft auch getsockopt mit SO_MAX_MSG_SIZE?

SO_MAX_MSG_SIZE liefert dir die maximale Größe eines Datagramms. Bei UDP also 64kb....