[PATCH] ipv4: Improve martian logs

[PATCH] ipv4: Improve martian logs

[Clara Engler]

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 <ROUTABLE IP>"
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]: <https://backreference.org/2010/03/26/tuntap-interface-tutorial>
[^2]: sysctl net.ipv4.ip_forward=1 && \
      iptables -A INPUT -i tun0 -j ACCEPT && \
      iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[^3]: <https://lore.kernel.org/all/aSd4Xj8rHrh-krjy@4944566b5c925f79/>

Signed-off-by: Clara Engler <cve@cve.cx>
---
 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

Re: [PATCH] ipv4: Improve martian logs

[David Ahern]

On 1/1/26 5:51 AM, Clara Engler wrote:
> 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 <ROUTABLE IP>"
> 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]: <https://backreference.org/2010/03/26/tuntap-interface-tutorial>
> [^2]: sysctl net.ipv4.ip_forward=1 && \
>       iptables -A INPUT -i tun0 -j ACCEPT && \
>       iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> [^3]: <https://lore.kernel.org/all/aSd4Xj8rHrh-krjy@4944566b5c925f79/>
> 
> Signed-off-by: Clara Engler <cve@cve.cx>
> ---
>  net/ipv4/route.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 


Reviewed-by: David Ahern <dsahern@kernel.org>

Re: [PATCH] ipv4: Improve martian logs

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu,  1 Jan 2026 13:51:14 +0100 you wrote:
> 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.
> 
> [...]

Here is the summary with links:
  - ipv4: Improve martian logs
    https://git.kernel.org/netdev/net-next/c/48a4aa9d9c39

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html