From: Clara Engler <cve@cve.cx>

At the current moment, the log message for packets with a martian source
IP address is wrong.  In fact, the current syntax looks as follows:

```
martian source <DESTINATION> from <SOURCE>, on dev <DEV>
```

This is wrong because `<SOURCE>` and `<DESTINATION>` need to be swapped.

Another verification for this claim can be seen when looking at the
(correct) implementation for logging packets with a martian destination
IP address, which happens to be identical, as it can be seen in line
2477 on the same file.

Signed-off-by: Clara Engler <cve@cve.cx>
---
 net/ipv4/route.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index b549d6a57307..913de56d2c2d 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1796,7 +1796,7 @@ static void ip_handle_martian_source(struct net_device *dev,
 		 *	the only hint is MAC header.
 		 */
 		pr_warn("martian source %pI4 from %pI4, on dev %s\n",
-			&daddr, &saddr, dev->name);
+			&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,
-- 
2.50.1 (Apple Git-155)

On Wed, 26 Nov 2025 22:59:58 +0100 Clara Engler wrote:
> @@ -1796,7 +1796,7 @@ static void ip_handle_martian_source(struct net_device *dev,
>  		 *	the only hint is MAC header.
>  		 */
>  		pr_warn("martian source %pI4 from %pI4, on dev %s\n",
> -			&daddr, &saddr, dev->name);
> +			&saddr, &daddr, dev->name);

imagine there was another comma in this print:

	martian source, %pI4 from %pI4, on dev %s

we should leave it as is, I think.
People may be grepping logs for this exact format..
-- 
pw-bot: reject

On Thu, Nov 27, 2025 at 06:17:43PM -0800, Jakub Kicinski wrote:
> imagine there was another comma in this print:
> 
> 	martian source, %pI4 from %pI4, on dev %s
> 
> we should leave it as is, I think.

Yes, this comma indeed makes it more helpful.

Personally, my preference would lie in a format such as the following:

    martian source (src={SRC}, dst={DST}, dev={DEV}

with a respective similar change to the martian destination.

> People may be grepping logs for this exact format..

I agree with you partially.  For such a trivial change, it is probably
not worth to pursue this any further, but I don't think "log stability"
is something to aim for/guarantee.

Thank You
Clara

On Fri, 28 Nov 2025 17:47:33 +0100 Clara Engler wrote:
> > People may be grepping logs for this exact format..  
> 
> I agree with you partially.  For such a trivial change, it is probably
> not worth to pursue this any further, but I don't think "log stability"
> is something to aim for/guarantee.

Could you explain how you discovered the issue?  (it should ideally be
part of the commit msg TBH)

On Fri, Nov 28, 2025 at 10:47:12AM -0800, Jakub Kicinski wrote:
> Could you explain how you discovered the issue?  (it should ideally be
> part of the commit msg TBH)

In the past few days, I toyed around with TUN interfaces and using them
as a tunnel (receiving packets via a TUN 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 routeable IP address on the internet led to them being treated as a
martian packet, obviously.  I was able to fix this with some sysctl's
and iptables settings, but while debugging I found the log message
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 <ROUTEABLE IP>" could also be falsely
interpreted as the response packet being martian, due to the word
"source" followed by the routeable IP address, implying the source
address of that packet is set to this IP.

[^1]: https://backreference.org/2010/03/26/tuntap-interface-tutorial

On Mon, 1 Dec 2025 19:54:23 +0100 Clara Engler wrote:
> On Fri, Nov 28, 2025 at 10:47:12AM -0800, Jakub Kicinski wrote:
> > Could you explain how you discovered the issue?  (it should ideally be
> > part of the commit msg TBH)  
> 
> In the past few days, I toyed around with TUN interfaces and using them
> as a tunnel (receiving packets via a TUN 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 routeable IP address on the internet led to them being treated as a
> martian packet, obviously.  I was able to fix this with some sysctl's
> and iptables settings, but while debugging I found the log message
> 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 <ROUTEABLE IP>" could also be falsely
> interpreted as the response packet being martian, due to the word
> "source" followed by the routeable IP address, implying the source
> address of that packet is set to this IP.
> 
> [^1]: https://backreference.org/2010/03/26/tuntap-interface-tutorial

I see. Sounds legit, we can adjust the error msg per you suggestion.
Unfortunately, we just entered a merge window and then there will be 
an end-of-year shutdown period so you'll need to post v2 in around a
month :(

On Mon, Dec 01, 2025 at 11:40:25AM -0800, Jakub Kicinski wrote:
> I see. Sounds legit, we can adjust the error msg per you suggestion.
> Unfortunately, we just entered a merge window and then there will be 
> an end-of-year shutdown period so you'll need to post v2 in around a
> month :(

Alright, will come back to it at the start of next year!