Frank Cox wrote:
A little clarification, a "martian source" isn't strictly an invalid IP. It is usually triggered when the kernel routing table doesn't match where it expects the IP address. I see this a lot on my firewall, but that is because both my ISP and myself use a 10.x.x.x private IP range that overlaps. They use it for the management of the cable modems, and I use it for more traditional uses. This results in my firewalls Kernel expecting 10.x to come in on eth3, not eth1 so the kernel fires off a martian source message with the details of the problem.On Thu, 30 Oct 2008 16:23:34 -0700 Aldo Foot <lunixer@xxxxxxxxx> wrote:Oct 28 08:53:28 myhost kernel: martian source 255.255.255.255 fromwhat do they mean?A "martian source" is an invalid IP address. In your case, 255.255.255.255 is the IP address. It's impossible for that to be a valid address, not least because *.*.*.255 is a broadcast address.
In terms of a broadcast range, since most proper broadcasts on more up to date TCP stacks use x.x.x.255 as the broadcast, not a full 'every network possible' broadcast (255.255.255.255) it will fire off an alert that something it trying a mass broadcast that it doesn't expect (since that broadcast range will not match its known route table). This broadcast IP can be seen a lot on DHCP type setups, or other discovery items on a computer. You can also see occasional 224-236.x.x.x ranges fire off the same messages on the box, for multicast messages.
A good example of a non-invalid IP address message is off my firewall(Sanitized a bit, of course):
Oct 29 01:39:08 fw kernel: martian source 192.168.1.1 from 68.10.11.12, on dev eth1 Oct 29 01:39:08 fw kernel: ll header: 00:e0:81:2a:1f:b8:00:30:b8:c6:c3:90:08:00 Oct 29 01:39:11 fw kernel: martian source 192.168.1.1 from 68.10.11.12, on dev eth1 Oct 29 01:39:11 fw kernel: ll header: 00:e0:81:2a:1f:b8:00:30:b8:c6:c3:90:08:00 Oct 29 01:39:11 fw kernel: martian source 192.168.1.1 from 68.10.11.12, on dev eth1 Oct 29 01:39:11 fw kernel: ll header: 00:e0:81:2a:1f:b8:00:30:b8:c6:c3:90:08:00
To break it down simply, there is a problem with how the routes are seeing the end results of my firewall as the wrong source (The internal gateway versus the public IP) with eth1 being the interface with the 68 address assigned.
Not to completely shoot down the last response, but it is an invalid address, that is true, same as any of the private IP ranges are seen on the Internet.
Sorry for the long winded reply, but this was something I know pretty well since I see it a lot.
Regards, Seann
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
