At the current moment, the logs for martian packets are as follows: ``` martian source {DST} from {SRC}, on dev {DEV} martian destination {DST} from {SRC}, dev {DEV} ``` These messages feel rather hard to understand in production, especially the "martian source" one, mostly because it is grammatically ambitious to parse which part is now the source address and which part is the destination address. For example, "{DST}" may there be interpreted as the actual source address due to following the word "source", thereby implying the actual source address to be the destination one. Personally, I discovered this bug while toying around with TUN interfaces and using them as a tunnel (receiving packets via a TUN interface and sending them over a TCP stream; receiving packets from a TCP stream and writing them to a TUN).[^1] When these IP addresses contained local IPs (i.e. 10.0.0.0/8 in source and destination), everything worked fine. However, sending them to a real routable IP address on the internet led to them being treated as a martian packet, obviously. Using a few sysctl(8) and iptables(8) settings[^2] fixed it, but while debugging I found the log message starting with "martian source" rather confusing, as I was unsure on whether the packet that gets dropped was the packet originating from me or the response from the endpoint, as "martian source " could also be falsely interpreted as the response packet being martian, due to the word "source" followed by the routable IP address, implying the source address of that packet is set to this IP, as explained above. In the end, I had to look into the source code of the kernel on where this error message gets generated, which is usually an indicator of there being room for improvement with regard to this error message. In terms of improvement, this commit changes the error messages for martian source and martian destination packets as follows: ``` martian source (src={SRC}, dst={DST}, dev={DEV}) martian destination (src={SRC}, dst={DST}, dev={DEV}) ``` These new wordings leave pretty much no room for ambiguity as all parameters are prefixed with a respective key explaining their semantic meaning. See also the following thread on LKML.[^3] [^1]: [^2]: sysctl net.ipv4.ip_forward=1 && \ iptables -A INPUT -i tun0 -j ACCEPT && \ iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE [^3]: Signed-off-by: Clara Engler --- net/ipv4/route.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index b549d6a57307..05f8c550a915 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1795,8 +1795,8 @@ static void ip_handle_martian_source(struct net_device *dev, * RFC1812 recommendation, if source is martian, * the only hint is MAC header. */ - pr_warn("martian source %pI4 from %pI4, on dev %s\n", - &daddr, &saddr, dev->name); + pr_warn("martian source (src=%pI4, dst=%pI4, dev=%s)\n", + &saddr, &daddr, dev->name); if (dev->hard_header_len && skb_mac_header_was_set(skb)) { print_hex_dump(KERN_WARNING, "ll header: ", DUMP_PREFIX_OFFSET, 16, 1, @@ -2475,8 +2475,8 @@ ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr, RT_CACHE_STAT_INC(in_martian_dst); #ifdef CONFIG_IP_ROUTE_VERBOSE if (IN_DEV_LOG_MARTIANS(in_dev)) - net_warn_ratelimited("martian destination %pI4 from %pI4, dev %s\n", - &daddr, &saddr, dev->name); + net_warn_ratelimited("martian destination (src=%pI4, dst=%pI4, dev=%s)\n", + &saddr, &daddr, dev->name); #endif goto out; -- 2.52.0