Your underlying transport will need to handle more than 1500 byte packets if bridging Ethernet-like interfaces. This can be handled with 802.11 links, as they support an MTU of 2304. This is a tunnel challenge, in general, as fragmentation of packets within the tunnel can't determine the sender of the "inner" packet that needs to get the ICMP fragmentation required message. Symptoms of this are that ping works, but ssh connections (that fill packets to their MTU) fail. If the bridge over the L2 GRE is "directly involved" then it confusingly works, apparently as the source/destination interface sees the reduced MTU of the bridge.
Also be careful with interface naming in UCI as gre4t-abcd.1234
is at the 15-character limit for interface names in the kernel.
From a previously running config of mine (the 172.16.1.NN/24 addresses are on the underlying 802.11s mesh interfaces that are configured elsewhere for a 2304 MTU):
# Give it plenty of MTU
# 14 Ethernet header
# 4 VLAN tag
# 4 Ethernet CRC
# 20 IPv4 delivery
# 8 GRE
# 4 GRE key
# 4 GRE sequence
# --
# 58 total
config interface 'gt98'
option proto 'gretap'
option mtu 1558
option ipaddr '172.16.1.99'
option peeraddr '172.16.1.98'
option delegate '0'
# Multiple, similar declarations for the other tunnels follow
config interface 'vlanNNNN'
option type 'bridge'
option stp '1'
option ifname 'eth1.NNNN @gt95.NNNN @gt96.NNNN @gt97.NNNN @gt98.NNNN'
option proto 'static'
option ipaddr '10.11.12.99'
option netmask '255.255.255.0'
option delegate '0'
Edit: I don't know why it needed to be @gt95.NNNN
but, as I recall, it didn't seem to work with just gt95.NNNN
The approach I now use for setting the MTU of the underlying mesh I've documented at
https://openwrt.org/docs/guide-user/network/wifi/mesh/batman#s_encrypted_authenticated_mesh
(I previously "hooked" the netifd
scripts to set the MTU directly, rather than using UCI configuration.)