# Tcpdump: ICMP-Pakete innerhalb eines GRE-Tunnels mitschneiden

**URL:** <https://forum.freifunk.net/t/tcpdump-icmp-pakete-innerhalb-eines-gre-tunnels-mitschneiden/16441>\
**Category:** Erklärbär\
**Created:** [24. Januar 2018 um 02:00 UTC](https://forum.freifunk.net/t/tcpdump-icmp-pakete-innerhalb-eines-gre-tunnels-mitschneiden/16441 "2018-01-24T02:00:37Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![MPW](https://forum.freifunk.net/user_avatar/forum.freifunk.net/mpw/32/4433_2.png) [@MPW](https://forum.freifunk.net/u/MPW)\
**Post date:** [24. Januar 2018 um 02:00 UTC](https://forum.freifunk.net/t/tcpdump-icmp-pakete-innerhalb-eines-gre-tunnels-mitschneiden/16441/1 "2018-01-24T02:00:38Z")

</div>

Tcpdump kann auch in GRE-Tunnel hineinsehen und dort ICMP-Pakete sichtbar machen.

Zunächst filtert man dazu auf GRE-Pakete:

```
 tcpdump -i any proto GRE

```

oder direkt über die [Protokollnummer 47, die GRE zugeordnet ist](https://de.wikipedia.org/wiki/Protokoll_(IP)).

```
 tcpdump -i any proto 47

```

In der Ausgabe sollten die gesuchten Pakete schon enthalten sein, aber auch noch viele weitere Pakete, die die Ausgabe unübersichtlich werden lassen. Daher kann die Ausgabe noch auf ICMP-Pakete innerhalb des Tunnels eingeschränkt werden.

Da - zumindest unter Debian 8 - das [protochain-Protokoll für GRE](https://serverfault.com/questions/684658/filtering-gre-enacpsulated-packets-with-tcpdump) nicht funktioniert, muss die Verschiebung im Header per Hand ausgerechnet werden.

Ein GREv0-Paket hat einen Header von 24 Oktetten (Bytes). [ICMP hat die Protokollnummer](https://de.wikipedia.org/wiki/Protokoll_(IP)) 0x01 und diese steht [im Header im 10. Oktett](https://de.wikipedia.org/wiki/Protokoll_(IP)), also plus neun, weil ab null gezählt wird.

Also muss das 33. Byte des Pakets die Hexadezimalzahl 0x01 enthalten:

```
 tcpdump -i any proto 47 and ip[33]=0x01

```

Möchte man zusätzlich noch auf eine Quell- oder Ziel-IP im ICMP-Paket filtern, so steht diese drei Oktetten / Bytes weiter hinten bzw. die Ziel-IP nochmal weitere vier, weil eine IPV4-Adresse 32 Bit also 4 Oktetten lang ist. Die Länge des zu betrachtenden Abschnitts kann in der eckigen Klammer durch einen Doppelpunkt getrennt als zweites Argument übergeben werden.

Die IP-Adresse muss dabei in die Hexadezimalschreibweise umgewandelt werden. (Dazu gibt es diverse Dienste im Netz, beispielweise [diesen](https://www.miniwebtool.com/ip-address-to-hex-converter/).)

**Beispiel:** Man möchte in einem GRE-Tunnel alle ICMP-Pakete von oder zur IP 100.64.7.186 filtern. Die Hexadezimalschreibweise dieser IP ist 0x644007B4.

```
tcpdump -i any proto 47 and ip[33]=0x01 and \( ip[36:4]==0x644007BA or ip[40:4]==0x644007BA \)

```

Ausgabe:

```
03:01:28.968786 IP gw03 > 185.66.195.1: GREv0, length 88: IP 185.66.194.49 > 100.64.7.186: ICMP echo request, id 13723, seq 1, length 64
03:01:28.987802 IP 185.66.195.1 > gw03: GREv0, length 88: IP 100.64.7.186 > 185.66.194.49: ICMP echo reply, id 13723, seq 1, length 64

```

Hier wurde ein Ping durch einen GRE-Tunnel zum FFRL-Backbone abgesetzt. Das erste Paket ist die ausgehende Anfrage, das zweite die eingehende Antwort.

Dies ist ein Wiki. Gerne Fehler korrigieren oder Ergänzungen vornehmen.
