#25192·openwrt

map.sh: option mtu is ignored for MAP-T (nat46) interfaces, leaving MTU at 16384

Author: kuxtuxCreated Sep 15, 2026Updated Sep 17, 2026
Labelstarget/x86bugOfficial ImageSupported Devicerelease/25.12

Describe the bug

proto_map_init_config() declares proto_config_add_int "mtu", but for maptype = map-t the value is never applied to the nat46 netdev, which keeps its default of 16384. The same option is honoured for map-e and lw4o6, which use an ip6tnl device.

With:

config interface 'wanmap'
	option proto 'map'
	option maptype 'map-t'
	option mtu '1480'
	option tunlink 'wan6'

the result is:

# ip link show dev map-wanmap
15: map-wanmap: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 16384 ...

OpenWrt version

r33051-f5dae5ece4

OpenWrt release

25.12.5

OpenWrt target/subtarget

x86/64

Device

Lenovo ThinkCentre M720q (10T8S0D200)

Image kind

Official downloaded image

Steps to reproduce

  1. Configure a proto map interface with option maptype 'map-t' and option mtu '1480'.
  2. ifup it and check ip link show dev map-<iface>.

Actual behaviour

MTU stays at 16384.

Expected behaviour

The device MTU should be set from option mtu, and should default to the tunlink MTU minus 20 rather than to 16384.

Additional info

MAP-T is a translation, not an encapsulation: a 1500-byte IPv4 packet becomes a 1520-byte IPv6 packet. With the WAN at 1500, full-size packets are dropped. And because the IPv4 MTU advertised locally is 16384, no ICMP fragmentation needed is ever generated back to the LAN host: the path is a black hole. Small exchanges (DNS, TCP handshakes) succeed while any real transfer stalls — a classic and time-consuming symptom. option mtu_fix '1' on the firewall zone does not help either, since MSS clamping follows the (wrong) device MTU.

Workaround:

bash
# /etc/hotplug.d/iface/99-mapt-mtu
[ "$ACTION" = "ifup" ] && [ "$INTERFACE" = "wanmap" ] && \
    ip link set dev "$DEVICE" mtu 1480

Related to the MAP-T investigation in issue #____ (odhcp6c).

Diffconfig

Terms

  • I am reporting an issue for OpenWrt, not an unsupported fork.