Log Dejargonizer

Linux kernel · Event martian source

Kernel: martian source — a packet arrived from the wrong direction

The kernel received a packet whose source address could not legitimately have come from that interface, and dropped it. The name is old networking slang for an address from nowhere. It is usually a routing mistake on your own network, not an attack.

Also written as IPv4 martian sourcekernel martian source logmartian destination linuxrp_filter martian source

What it means for you

For an analyst

This is reverse path filtering rejecting a packet: the kernel checked whether it would route a reply to that source back out the same interface and found it would not. Strict mode is where most of these come from, and it breaks legitimately asymmetric designs — multihomed hosts, some VPN topologies, and anycast setups. Loose mode is the usual compromise. Note the message dumps the packet header bytes, which is the only place you get the full frame, and the 'll header' at the end contains the source MAC — that is how you identify which device on the segment is actually sending it, which no amount of IP-level analysis will tell you.

The fields that decide it

Everything else in the log line is context.

source and 'from'
The two addresses in the message. The first is the destination and the second the source, which reads backwards to most people and causes constant confusion.
on dev
Which interface it arrived on. This is what the reverse path check was performed against, and the field that identifies the misrouted path.
ll header
The link-layer header bytes at the end of the message. The source MAC address is in there, and it is the only reliable way to identify the device actually transmitting.
rp_filter setting
Not in the message, but what generated it.
  • 2 (loose)Accepts a packet if the source is reachable via any interface. Usually the right choice on a multihomed host.
  • 1 (strict)Requires the reply route to use the same interface. Correct for simple topologies and the source of most martian messages.
  • 0 (off)No reverse path checking. Silences the messages by removing the check, which is rarely what you want.

Common questions

Is a martian source packet an attack?

Occasionally it is spoofed traffic, which is what the check exists to stop. Far more often it is your own network: asymmetric routing, a host with two interfaces on the same subnet, a misconfigured VPN, or a device with a stale static route. Start by assuming a routing mistake, because that is what it nearly always turns out to be.

How do I read the martian source message? The addresses look backwards.

They are. The address immediately after 'martian source' is the destination, and the one after 'from' is the source. This trips up almost everyone the first time and sends people chasing the wrong host. Read it as: a packet destined for the first address, claiming to come from the second, arrived on this interface and should not have.

How do I find which device is sending martian packets?

Use the link-layer header at the end of the message. The first six bytes are the destination MAC and the next six are the source MAC — look that up in your switch's address table and it identifies the physical port. Chasing the IP address alone is unproductive precisely because the address is the part that does not make sense.

Should I turn off rp_filter to stop these messages?

Not to silence a log. If the traffic is legitimate and your topology is genuinely asymmetric, loose mode — rp_filter set to 2 — accepts it while still rejecting sources that are unreachable by any path. Turning the check off entirely removes a useful anti-spoofing control. And if you only want the noise gone, log_martians can be disabled independently while the filtering stays in place.

Read next

Mentioned by

Vendor documentation

Last reviewed 6 September 2026