Kernel icmp rate-limit

Hallo,

ich versuche gerade die Funktionsweise von 2 Kernel-Parametern zu ergründen.
Bevor da Fragen kommen, System + Kernel sind egal, HZ (hier 250) eigentlich auch, mir gehts ums Prinzip.

net.ipv4.icmp_ratelimit = 250
net.ipv4.icmp_ratemask = 6168
Das sind die default-Werte von nem Debian-Out-of-the-box

Ich teste indem ich mit WinMTR eine IP hinter dem Rechner mit 10pps antrace und gucke wie viel "loss" der Linux-Router hat.

Ich finde da diverse Erkärungen die alle in etwa wie folgt lauten:
http://www.securityfocus.com/infocus/1711

Together, these two variables allow you to limit how frequently specified ICMP packets are generated. icmp_ratelimit defines how many packets that match the icmp_ratemask per jiffie (a unit of time, a 1/100th of a second on most architectures) are allowed.

Zum Vergrößern anklicken....

Das würde für mich bedeuten, dass der Kernel mehr Pakete verschickt je höher der Wert ist, sprich bei nem Wert von 1 und 250HZ-Kernel bis zu 250Pakete/sec., beim Default-Wert 250*250= 62500 Pakete
In der Praxis ist es genau andersrun, sprich der scheint durch die Zahl zu teilen.
Schlumpf zu dumm oder Beschreibung falsch/schlecht ?

Kommen wir zum interessanten Teil:

The ratemask is a logical OR of all the ICMP codes you wish to rate limit. (See /usr/include/linux/icmp.h for the actual values.) The default mask includes destination unreachable, source quench, time exceeded and parameter problem. If you increase the limit, you can slow down or potentially confuse port scans, but you may inhibit legitimate network error indicators.

Zum Vergrößern anklicken....

in der icmp.h steht folgendes:

#define ICMP_ECHOREPLY 0 /* Echo Reply */
#define ICMP_DEST_UNREACH 3 /* Destination Unreachable */
#define ICMP_SOURCE_QUENCH 4 /* Source Quench */
#define ICMP_REDIRECT 5 /* Redirect (change route) */
#define ICMP_ECHO 8 /* Echo Request */
#define ICMP_TIME_EXCEEDED 11 /* Time Exceeded */
#define ICMP_PARAMETERPROB 12 /* Parameter Problem */
#define ICMP_TIMESTAMP 13 /* Timestamp Request */
#define ICMP_TIMESTAMPREPLY 14 /* Timestamp Reply */
#define ICMP_INFO_REQUEST 15 /* Information Request */
#define ICMP_INFO_REPLY 16 /* Information Reply */
#define ICMP_ADDRESS 17 /* Address Mask Request */
#define ICMP_ADDRESSREPLY 18 /* Address Mask Reply */
#define NR_ICMP_TYPES 18

Zum Vergrößern anklicken....

Kann mir das einer erklären was die da berechnen ?
Ich verstehe nicht was die da womit OR-verknüpfen. Wenn ich Werte mit OR verknüpfe kommt da immer 0 oder 1 raus

Dann ist in der Manpage zu icmp ein Parameter "icmp_timeexceed_rate" beschriben, ist das ein Relikt aus alten Zeiten ? Den find ich auf meinen Rechnern (ältester = 2.4.31 Kernel) nirgendwo.

edit:
Ich glaube der 2. Teil hat sich mit der binären Darstellung von 6168 (1100000011000) soeben erklärt.

Den 2. Teil hast du richtig erkannt, den 1. Teil richtig vermutet. Kleine Werte lassen mehr Pakete pro Zeiteinheit zu. In der mit dem Kernel mitgelieferten Doku (Documentation/networking/ip-sysctl.txt) steht:

icmp_ratelimit - INTEGER
Limit the maximal rates for sending ICMP packets whose type matches
icmp_ratemask (see below) to specific targets.
0 to disable any limiting,
otherwise the minimal space between responses in milliseconds.
Default: 1000

Hallo zusammen,
auch wenn dieser Beitrag schon etwas älter ist und meine Frage nicht genau darauf passt dachte ich aber das ihr mir sicher weiterhelfen könnt.
Seid Feb. 2014 haben wir Kunden des Regionalen Internetanbieters ACO-Connect aus Kassel arge Probleme mit sehr hohen Paketverlusten.
Diese treten hauptsächlich Abends und am Wochenende auf. Leider ist der Kundensupport nicht sonderlich hilfsbereit und schiebt nach langem hin und her das Problem auf AVM. Diese sollen im Fritzbox Kernel eben diesen ICMP-Ratelimit eingetragen haben und somit werden die Pakete von Teamspeak oder Onlinegames eben geblockt.
Ich kann mir das aber nicht vorstellen da es vorher ohne Probleme ging und Bekannte die auf dem selben Teamspeak Server sind wie ich und auch Besitzer einer Fritzbox sind zur gleichen Zeit 0% haben.
Da ich es nicht alleine bin sondern jeder aus meinem Ort der mir bekannt ist hat dieses Problem und auch die gleichen Werte wie ich zur gleichen Zeit.
ACO ist leider nicht mehr bereit sich dem Probelm weiter anzunehmen und haben uns Verboten den Support damit zu belästigen. Leider bin ich in einer Zwickmühle da ich keine alternative habe denn es gibt keinen anderen Anbieter der uns mehr als DSL-Light (384kb) bieten kann. (Wenn ich mal LTE mit Volumentarife ausser Acht lasse)
Der AVM Support hat mir erklärt das dieser Parameter zwar in der Firmware verankert ist aber nicht der Grund für die Paketverluste sein kann. Dies habe ich auch an den Provider weitergeleitet aber dies wird vollkommen ignoriert.

Könnt ihr mir erklären was dieser ICMP-Ratelimit macht bzw ob es wirklich Schuld sein kann?
Und wenn nicht wäre es möglich das ihr mir bei meinem Problem helfen könnt? Ich wäre euch sehr dankbar


Mfg cystix

cystix schrieb:

schiebt nach langem hin und her das Problem auf AVM. Diese sollen im Fritzbox Kernel eben diesen ICMP-Ratelimit eingetragen haben und somit werden die Pakete von Teamspeak oder Onlinegames eben geblockt.

Zum Vergrößern anklicken....

Grober Unfug.

cystix schrieb:

Der AVM Support hat mir erklärt das dieser Parameter zwar in der Firmware verankert ist aber nicht der Grund für die Paketverluste sein kann.

Zum Vergrößern anklicken....

Richtig.

ICMP-Pakete sind so eine Art "Sonderpakete für Fehlermeldungen" in IP-Netzen. Nur deren Zahl wird durch das ICMP-Ratelimit begrenzt. Auf die Übertragung der Nutzlast von Programmen wie Teamspeak und Spielen hat das Limit keinen Einfluß. Dieses Daten werden als UDP- oder TCP-Pakete verschickt, nicht als ICMP-Paket.

Dumm wirds nur, wenn ein Router bestimmte ICMP-Typen komplett sperrt. Besonders "clevere" Leute sperren ja gern alles, was sie nicht kennen, und schießen sich damit selbst in den Fuß. Darum gehts aber in deinem Fall nicht.

vielen dank für deine schnelle antwort.
Wie kann ich versuchen das dem Betreiber deutlich klar zu machen?

Hallo nochmal,
ich habe nochmals per Email kontakt zu meinem Provider aufgenommen.
Ich habe mit ihrer Erklärung versucht zu verdeutlichen das es doch nicht die ICMP - Pakete sind.
Natürlich kommt jetzt die Frage welche Pakete bei mri verloren gehen.
Habe ihnen TCP und UDP (wie sie es beschrieben haben) weitergegeben. Ich hoffe da kommt jetzt nochmal was ins rollen.


MfG Cystix
und nochmal vielen Dank für die Ausführliche Antwort

Ich habe tatsächlich schon eine Antwort bekommen.
ACO meint TCP und UDP sind Protokolle und somit keine Pakete.
Aber ICMP ist doch auch ein Protokoll? Verwalten die nicht den Paketfluss?
Die verarschen mich doch oder?

Kann sein, evtl. können die mit deinen Meldungen auch einfach nicht viel anfangen.
Ich hab auch hin und wieder nen Kunden, der z.B. Probleme nach Land xy reported.
Manche Infos sind halt leider zum Debuggen nutzlos.
Bei paketloss oder ähnlichen Problemen:
source-IP, destination IP und soweit möglich ein mtr in beide Richtungen mitschicken, damit kann man dann auch ordentlich arbeiten. Zudem soweit möglich dafür sorgen, dass der eigene Router pingt.

Evtl. solltest du denen auch einfach ein paar Beispielverbindungen senden.
Sprich Server mit der IP xy wird angepingt mit ICMP Paketen. Mittags 0 von 1000 Paketen verloren, Abends 18 von 1000 Paketen verloren.
Teamspeak-Server mit IP xy, UDP Port abcde. Mittags kein Loss, Abends Tonstörungen.

Wenn du Zugriff auf einen der "Problemserver" hast, kannst du natürlich auch mit tcpdump bzw. wireshark gleichzeitig nen dumpg auf Client und Server machen, dann kann man auch erkennen auf welcher Richtung die Pakete verloren gehen.