System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

RHEL server gives martian source logs cont...

SOLVED
Go to solution
Shehan
Super Advisor

RHEL server gives martian source logs cont...

Hi All

I am getting below massage continuously in RHEL server running Open Call Video platform.

Aug 1 05:17:17 ocmpvid kernel: ll header: ff:ff:ff:ff:ff:ff:00:03:d2:29:6b:ac:08:06
Aug 1 05:34:23 ocmpvid kernel: martian source 10.48.248.110 from 10.48.248.99, on dev bond2
Aug 1 05:34:23 ocmpvid kernel: ll header: ff:ff:ff:ff:ff:ff:00:03:d2:29:6b:ac:08:06

The major issue is its application seems to be not responding sometime and once the server is rebooted, it is coming to back to normal. Although I check the HW errors in the messege log , I could find this error except cdrom issue. Please let me know what this log is?

Regards
Nirukshitha


5 REPLIES
Steven E. Protter
Exalted Contributor
Solution

Re: RHEL server gives martian source logs cont...

Shalom,

Find the application vendor and see their website. You have not posted enough input for my crystal ball to provide output.

I suspect this is an application error and the application documents will tell you where they are stored.

You can look at the startup script in /etc/init.d and perhaps that will tell you where the logs are written. Perhaps not.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Shehan
Super Advisor

Re: RHEL server gives martian source logs cont...

Hi Steven

I believe this is LAN miss-configuration issue.

Anybody have felt this due to LAN issue?

Regards
Nirukshitha
Matti_Kurkela
Honored Contributor

Re: RHEL server gives martian source logs cont...

"Martian source" indicates that the kernel did not expect a packet with that source address to come in from that network interface (i.e. the kernel thinks "How the heck did THAT come in from THERE???").

This detection is based on network parameters and routing tables. Are you sure the netmasks of your route entries are correct? Please show us the output of "route -nv" from your network if possible.

"Martian source 10.48.248.110 from 10.48.248.99" would mean that 10.48.248.99 may have forwarded a packet from 10.48.248.110, which should be unnecessary if these two hosts are within the same subnet.
Examine all the network settings on both these hosts and correct if necessary.

The "ll header" message gives more information about the strange-looking packet. It is an Ethernet Link-Level Header, so you'll need this to analyze it:

http://en.wikipedia.org/wiki/EtherType

The preamble is omitted in the kernel message, so the destination address is ff:ff:ff:ff:ff:ff, an Ethernet-level broadcast address.
Source address is 00:03:d2:29:6b:ac. This may be useful in confirming the identity of the source machine.
The last 4 digits are the ethertype of the message. In this case, it's 08:06, identifying the protocol as ARP.

MK
MK
Shehan
Super Advisor

Re: RHEL server gives martian source logs cont...

Hi Matti

Thanks for the feedback. I have "netstat -nr" output in below.

This server is being placed in our client and still I don't what 10.48.248.99 is. Sometime it should be another server in the same network.

Does this issue may issue for the hang the server? If it is hang, it comes to back to normal after rebooting the system.


Regards
Nirukshitha
Matti_Kurkela
Honored Contributor

Re: RHEL server gives martian source logs cont...

No, receiving packets from strange source addresses should *never* crash or hang the server.
If it would do that, it would be a pretty awful kernel bug in the networking layers.

Does it help if you restart just the application? If it does, that would suggest the problem is within the application itself.

If there are multiple ways to reach some hosts (and especially if at least one of those ways is firewalled), it may be that the routing or the ARP tables are getting confused, making the server effectively unreachable.

If this is the problem, the "martian source" messages are just a harmless/annoying side effect of the network problem. A full knowledge of your network topology would be required to understand the problem and to design a fix in such a case.

Your "netstat -nr" seems to have the network 10.48.248.96 listed twice on bond0. I wonder why? Are you perhaps using Linux's advanced routing features?
------
10.48.248.96    0.0.0.0         255.255.255.240 U         0 0          0 bond0
10.48.248.96    0.0.0.0         255.255.255.240 U         0 0          0 bond0
------

If advanced routing (also known as "policy routing") is used, it is managed by the "ip" command. The ordinary "netstat -nr" may display incomplete information in such cases.

What is displayed by these commands?

ip route show
ip rule show
ip tunnel show

MK
MK