Clumsy

Der Name ist ungewöhnlich aber Entwickler aber auch Administratoren und Netzwerker sollten Clumsy kennen: Sie können damit auf ihrem Client das Netzwerk "schlechter" machen, als es in Realität ist.

Für wen ist Clumsy?

In einer idealen Welt sind Netzwerk zuverlässig, schnell, leistungsfähig und nie das Problem. In einer realen Welt sind Netzwerk oft die Ursache und viele Applikationsbetreuer und Entwickler verstehen das nicht. Das ist insbesondere der Fall, wenn Sie z.B. TCP als Transport-Protokoll nutzen und einfach darauf vertrauen, dass der darunter liegende Transport-Stack um alles kümmert. Das ist aber bei weitem nicht der Fall und wenn Pakete verloren gehen, dann kann es etwas dauern, bis die erneute Übertragung letztlich dazu führt, die Nutzdaten an die Applikation zu liefern. Die Applikation "wartet" dann einfach.

Clumsy kann hier helfen, denn Sie können damit genau diese Probleme simulieren. Nach dem Start sehen Sie direkt die Optionen, wie Clumsy ihr System absichtlich stören kann. Über Presets, die aus einer Textdatei kommen, können Sie Quellen und Ziele vorgeben und sich das Leben damit einfacher machen. Sie können natürlich manuell die Filter anpassen.

Erst einmal ist nichts aktiv, aber Sie können die verschiedenen Störungen aktivieren und dann die Richtung als auch die Wahrscheinlichkeit einstellen.

Je nach Anwendungsfall sind z.B. damit folgende Aufgabenstellungen möglich:

  • Netzwerk
    Wie gut funktioniert z.B. ihr Monitoring um z.B. "Retransmits" zu erkennen und damit auf Fehler zu schließen?
  • Programmierer
    Testen Sie ihre Applikation doch einmal unter "schlechten Verbindungen". Haben Sie wirklich die Threads sauber getrennt oder blockiert das Warten auf Daten die komplette Anwendung?
  • Consultants
    Ich selbst habe mit Clumsy z.B. einem Kunden zeigen können, wie sich Outlook mit "schlechten" Verbindungen verhält. Was On Premises mit einem lokalen Exchange Server noch perfekt funktioniert, muss über ein überlastetes WAN eben nicht mehr funktionieren.
  • VoIP
    Durch gezielte Veränderungen an den Parametern "Throttle" und "Drop" lässt sich gut das Verhalten eines VoIP Codecs unter verschiedenen Kennzahlen beobachten. Über "Throttle" drehen Sie die Jitter-Werte hoch und der VoIP Clients sollte seinen Jitter-Buffer verlängern. Wenn die eingehende "Loss"-rate hoch geht, sollt der Empfänger dies per RTCP an den Sender mitteilen, der dann einfach die Bandbreite reduziert. Das kann er durch einen Wechsel des Codec oder Reduzierung der Auflösung (VGA statt HD,  NarrowBand statt WideBand) kompensieren.
  • Skype Business QoE
    Die "verschlechterten Werte" sollten sich auch im QoE-Report von Skype for Business widerspiegeln und wenn Sie ein passendes Monitoring eingerichtet haben, dann müsste es Alarm schlagen.

Clumsy ist ein spezielles Werkzeug für besondere Einsatzfälle. Ich nutze es nicht allzu oft aber seit dem Tools wie Netzwerk Emulation / WAN Emulation nicht mehr zur Verfügung stehen, ist es fpr Labor und Testumgebungen sehr nützlich.

Eigene Filter

Im Programmverzeichnis gibt es eine "config.txt", in der einige Filter vordefiniert sind. Wenn Sie genau hinschauen, dann finden Sie am Anfang die Beschreibung gefolgt von einem "Doppelpunkt", nach dem dann die eigentliche Filterdefinition zu finden ist.

# filters presets. clumsy will capture packets base filter criteria
# each entry must contains single line
# filter-name:filter-text
# see <https://github.com/basil00/Divert/wiki/WinDivert-Documentation#7-filter-language> for details

# loopback packets can only be filtered using 'outbound'.
localhost ipv4 all: outbound and ip.DstAddr >= 127.0.0.1 and ip.DstAddr <= 127.255.255.255
localhost ipv4 tcp: tcp and outbound and ip.DstAddr >= 127.0.0.1 and ip.DstAddr <= 127.255.255.255
localhost ipv4 udp: udp and outbound and ip.DstAddr >= 127.0.0.1 and ip.DstAddr <= 127.255.255.255

# more general
all sending packets: outbound
all receiving packets: inbound

# more specific
all ipv4 against specific ip: ip.DstAddr == 198.51.100.1 or ip.SrcAddr == 198.51.100.1
tcp ipv4 against specific ip: tcp and (ip.DstAddr == 198.51.100.1 or ip.SrcAddr == 198.51.100.1)
udp ipv4 against specific ip: udp and (ip.DstAddr == 198.51.100.1 or ip.SrcAddr == 198.51.100.1)
all ipv4 against port: ip.DstPort == 12354 or ip.SrcPort == 12354 
tcp ipv4 against port: tcp and (tcp.DstPort == 12354 or tcp.SrcPort == 12354)
udp ipv4 against port: udp and (udp.DstPort == 12354 or udp.SrcPort == 12354)

# ipv6 is supported but usually not that useful
ipv6 all: ipv6

# you can add your usual filters here for your own use:
#http requests ONLY(data transmit on other ports): outbound and tcp.DstPort == 80

Ich habe mir zumindest für UDP und ein paar TCP-Ports noch folgende Zeilen addiert:

MSXFAQ TURN-UDP: udp and outbound and udp.DstPort == 3478
MSXFAQ RTP Audio: udp and (udp.SrcPort >= 50000 and udp.SrcPort <= 50059)

Denken Sie daran, dass sie auch eingehende Pakete stören können aber auf dem Kabel dass das Netzwerk nichts sieht, sondern die Störung erst nach dem Empfang durch die Netzwerkkarte erfolgt.

Download und Start

Clumsy habe ich auf folgender URL gefunden und muss nicht einmal klassisch installiert werden

clumsy 0.2
https://jagt.github.io/clumsy/download.html
clumsy makes your network condition on Windows significantly worse, but in a managed and interactive manner.

Packen Sie das Archiv einfach in ein leeres Verzeichnis aus. Sie finden darin folgende vier Dateien, von denen aber nur die WinDivert64.sys auch digital signiert ist.

Ein wenig Vertrauen müssen Sie da schon mitbringen, dieses Programm als Administrator zu starten. Ansonsten kann es die Pakete nicht beeinflussen.

Weitere Links