search

Jamesits / linux-gre-keepalive

High-performance passive (a.k.a. reply-only) GRE keepalive support for Linux, written in eBPF/XDP.
GNU General Public License v2.0
54 stars 8 forks source link

why the type is 0x0004 #3

Closed someonebw closed 2 years ago

Jamesits commented 2 years ago

I think Huawei implemented a slightly different packet format for sending GRE replies.

This one is a normal, Cisco-compatible GRE keepalive packet, with outer GRE protocol 0x0800 (IPv4). image

This one is a GRE packet with outer GRE protocol 0x0004 (unassigned), so Wireshark cannot decode it. But if you watch close enough, you might discover that the data segment is still an IPv4 packet (src=36.26.87.125, dst=111.47.24.27, proto=0x2f/GRE). I've underlined the IP addresses on the picture. image

My guess is that Huawei is trying to probe what kind of a device is at the opposite of the tunnel. Unfortunately I don't have any Huawei routers in my lab and I cannot find any documentation on the internet about this behavior. If you want to further experiment on this packet type, you can patch this line:

https://github.com/Jamesits/linux-gre-keepalive/blob/702969c099c86a740a5c2c058446455896bd402a/src/keepalive_gre.c#L81=

add a || outer_grehdr -> proto == bpf_htons(0x0004) match condition here.

Jamesits commented 2 years ago

Yes, I think your conclusion is correct.

BTW, what's your kernel version? It might be related to a kernel bug.