Problems with if_gre

[Bruce M Simpson]

Further searching turned up a post on the Quagga-users list which suggested
TTL might be the culprit.

I bounce the interface using ifconfig to recreate the interface route
in the routing table, then throw tcpdump extra options to monitor MTU,
as well as running route -nv monitor in the background:-

The cisco doesn't respond:

23:17:16.197493 0:4:76:5e:ec:7d 0:2:b3:8d:23:e4 0800 122: saboteur > bms-gre-eth0: gre 172.16.1.2 > 172.16.1.1: icmp: echo request (ttl 64, id 30027, len 84) (ttl 30, id 30729, len 108, bad cksum 0!)

There is no RTM_MISS message recorded by route monitor.

If I try in the opposite direction:-
23:18:05.184120 0:50:54:80:6:98 0:4:76:5e:ec:7d 0800 138: bms-gre-eth0 > saboteur: gre 172.16.1.1 > 172.16.1.2: icmp: echo request (ttl 255, id 39, len 100) (ttl 255, id 37, len 124)
23:18:05.184241 0:4:76:5e:ec:7d 0:2:b3:8d:23:e4 0800 138: saboteur > bms-gre-eth0: gre 172.16.1.2 > 172.16.1.1: icmp: echo reply (ttl 64, id 18208, len 100) (ttl 30, id 49163, len 124, bad cksum 0!)

The Cisco's ICMP echo request is being correctly de-encapsulated by FreeBSD,
It hits icmp_reflect() in the kernel, hence the correctly generated echo
reply message.

I can't find any evidence of an RTM_MISS, though - and the above capture
is on a physical interface. I could try inserting a dumb non-switching hub
and inspecting packet capture from another machine on the same segment
as the Cisco to be sure the packet really is hitting the Cisco, but given
that the link-layer addresses are correct after if_gre processing, this
doesn't seem to be the problem.

One thing leaps out at me here though - 122 vs 138. Ciscos send 100-byte
pings by default. Casual inspection of the headers suggests that they
are the same length. The payloads appear to begin at the same offset
in the frame.

Still scratching my head.

BMS