Martian Sources

English Network/Internet
#1

I have recently installed my laptop to OpenSUSE 11.0. I am working on tweaking some of the settings and when I went to see my /var/log/messages, I have a flood of martian source log entries appearing in intervals of 5 seconds. Needless to say, its filling up my log files that look like this:

Jun 24 16:09:17 linux-scuq kernel: printk: 25 messages suppressed.
Jun 24 16:09:17 linux-scuq kernel: martian source 10.100.1.0 from 0.0.0.0, on dev eth0
Jun 24 16:09:17 linux-scuq kernel: ll header: 01:00:5e:64:01:05:00:00:00:00:fe:01:08:00

I searched the forums and found an archived thread that covers this:
Martian Source - openSUSE Forums

I added the following lines to the /etc/sysctl.conf file

net.ipv4.conf.eth0.log_martians = 0
net.ipv4.conf.wlan0.log_martians = 0

/etc/init.d/boot.sysctl is set to startup automatically and when it starts I get the following output:

Setting current sysctl status from /etc/sysctl.conf
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
fs.inotify.max_user_watches = 65536
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
net.ipv4.conf.eth0.log_martians = 0
net.ipv4.conf.wlan0.log_martians = 0

which leads me to believe it should be working, however when I check my logs, same situation.

Anybody have any additional ideas?

#2

I was able to find out a method of disabling these messages. I do not use IPV6 and the messages that remained in /var/log/messages were from the ipv6 stack not ipv4 (which is what the entries in /etc/sysctl.conf were suppressing).

To disable ipv6 on opensuse 11.0 so I do not see these messages I simply did the following two commands as root:

echo “alias net-pf-10 off” >> /etc/modprobe.conf
echo “alias ipv6 off” >> /etc/modprobe.conf

Then rebooted.

#3

Martian sources a packets that come from an unroutable network. Most home users run networks in the unroutable ‘192.168.0.x’ range and will generally get martian source events. In this environment, you can ignore these events.

#4

You might want to echo those to /etc/modprobe.conf.local since the future upgrades will most likely overwrite /etc/modprobe.conf as expected.

modprobe.conf.local is referenced to be included from within modprobe.conf already too, btw.

#5

/etc/sysconfig/SuSEfirewall2

17.)

Do you want to enable additional kernel TCP/IP security features?

If set to yes, some obscure kernel options are set.

(icmp_ignore_bogus_error_responses, icmp_echoreply_rate,

icmp_destunreach_rate, icmp_paramprob_rate, icmp_timeexeed_rate,

ip_local_port_range, log_martians, rp_filter, routing flush,

bootp_relay, proxy_arp, secure_redirects, accept_source_route

icmp_echo_ignore_broadcasts, ipfrag_time)

Tip: Set this to “no” until you have verified that you have got a

configuration which works for you. Then set this to “yes” and keep it

if everything still works. (It should!) :wink:

Choice: “yes” or “no”, if not set defaults to “yes”

FW_KERNEL_SECURITY=“no”

Changing this option in the SuSEfirewall2 config file fixed this issue for me. I verified my Samba and NFS shares are still working so I’m not sure what else this changes.

Hope this helps.

#6

Not quite. The kernel doesn’t have any hardwired idea of the private subnet ranges. In any case those addresses are not unroutable. They are just as routeable as any other address, it’s just that on the public Internet, by common agreement, nobody will route those. In fact ISP often use them internally, assigning them to internal routers that move packets around. No precious public addresses are used with this practice. Do a traceroute sometime and you will see your packets traverse many an internal router in your ISP’s network.

What a martian packet is actually one with a destination IP that is not expected on the interface in question. For example if you are running a 192.168.0.0/24 subnet and you put another subnet on the switch with a 10. address, you will get martians. You really need some VLANs to separate the subnets, but maybe you have only a simple switch.

You could also get into a martian situation by a typo, e.g. assigning a host a 192.169. address by mistake.

See here Martian packet - Wikipedia, the free encyclopedia

#7

Hi,

I found that martian source log events were caused by a line in /etc/sysconfig/SuSEfirewall2 contained the directive

FW_KERNEL_SECURITY=“yes”

You might want to set this to “no”, but if you like the security features and don’t want to turn it off, you can comment out the line (around 941) in /sbin/SuSEfirewall2 which says “setproc 1 $i/log_martians”

If you patch update or re-apply SuSEfirewall2, then this change may be undone, re-introducing martian log messages.

Regards

Warwick