Martian source from localhost on eth0

From: Jan Bols (jan_at_ivpv.ugent.be)
Date: 07/14/03 

Date: Mon, 14 Jul 2003 10:38:24 +0200

I run a Linux Mandrake 9.1 server. Ever since a new motherboard was
installed I get the following message in my logs:

--- /var/log/messages ---

Jul 14 10:11:23 plato kernel: martian source 255.255.255.255 from
127.0.0.1, on dev eth0
Jul 14 10:11:23 plato kernel: ll header:
ff:ff:ff:ff:ff:ff:00:d0:59:2d:c5:28:08:00 

---
This occurs about every 2 minutes.
I know I can disable the logging of the event or drop the packet from 
the firewall. However I would like to know what causes this packet to be 
sent.
I did a search on Google and found a number of postings of people with 
exactly the same problem, but no-one could explain the reason why this 
strange packet occurs.
Running Ethereal I was able to capture the packet. Below you can find 
the printout...
--- ethereal printout ---
Frame 1 (62 bytes on wire, 62 bytes captured)
     Arrival Time: Jul  9, 2003 16:45:25.442258000
     Time delta from previous packet: 0.000000000 seconds
     Time relative to first packet: 0.000000000 seconds
     Frame Number: 1
     Packet Length: 62 bytes
     Capture Length: 62 bytes
Linux cooked capture
     Packet type: Broadcast (1)
     Link-layer address type: 1
     Link-layer address length: 6
     Source: 00:d0:59:2d:c5:28 (AmbitMic_2d:c5:28)
     Protocol: IP (0x0800)
     Trailer: 000000000000
Internet Protocol, Src Addr: 127.0.0.1 (127.0.0.1), Dst Addr: 
255.255.255.255 (255.255.255.255)
     Version: 4
     Header length: 20 bytes
     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
         0000 00.. = Differentiated Services Codepoint: Default (0x00)
         .... ..0. = ECN-Capable Transport (ECT): 0
         .... ...0 = ECN-CE: 0
     Total Length: 40
     Identification: 0xe424
     Flags: 0x00
         .0.. = Don't fragment: Not set
         ..0. = More fragments: Not set
     Fragment offset: 0
     Time to live: 128
     Protocol: UDP (0x11)
     Header checksum: 0xd79f (correct)
     Source: 127.0.0.1 (127.0.0.1)
     Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 2301 (2301), Dst Port: 2301 (2301)
     Source port: 2301 (2301)
     Destination port: 2301 (2301)
     Length: 20
     Checksum: 0x7c9a (correct)
Data (12 bytes)
0000  00 01 00 01 00 06 00 d0 59 2d c5 28 08 77 08 00   ........Y-.(.w..
0010  45 00 00 28 e4 24 00 00 80 11 d7 9f 7f 00 00 01   E..(.$..........
0020  ff ff ff ff 08 fd 08 fd 00 14 7c 9a 01 00 00 30   ..........|....0
0030  a9 c1 0b 3f 3c 00 00 00 00 00 00 00 00 00         ...?<.........
---
As you can see, the source HW address is 00:d0:59:2d:c5:28. However, 
there is no machine with that HW address running in my sub network. The 
HW address of the machine that causes/reports the problem is 
00:50:BA:A7:66:A5 as you can see from the ifconfig result...
--- ifconfig ---
eth0      Link encap:Ethernet  HWaddr 00:50:BA:A7:66:A5
           inet addr:157.193.82.130  Bcast:157.193.82.255 
Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:16747299 errors:1 dropped:142 overruns:0 frame:91
           TX packets:27434489 errors:0 dropped:0 overruns:0 carrier:0
           collisions:1176718 txqueuelen:100
           RX bytes:1643408363 (1567.2 Mb)  TX bytes:332391888 (316.9 Mb)
           Interrupt:17 Base address:0xe400
lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:4803589 errors:0 dropped:0 overruns:0 frame:0
           TX packets:4803589 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:4191240137 (3997.0 Mb)  TX bytes:4191240137 (3997.0 Mb)
---
Can you give me a rational explanation for this behaviour? Do I have a 
mad network card? Are aliens attacking our network from the inside? Or 
did I simply miss something obvious?
Jan Bols

Relevant Pages

  • IP protocol checksum errors
    ... Frame 3484 ... Time delta from previous packet: ... Capture Length: 254 bytes ... Fragment offset: 0 ...
    (comp.os.linux.embedded)
  • RE: Snort + (OpenBSD or Linux)
    ... Snort + (OpenBSD or Linux) ... >on the same packet. ... Regarding OpenBSD vs. Linux packet capture performance (this is a really old ...
    (Focus-IDS)
  • [TOOL] WinPcap, the Free Packet Capture Architecture for Windows
    ... the Free Packet Capture Architecture for Windows ...
    (Securiteam)
  • Re: How to go about developing a TCP Packet Filter
    ... You can modify and capture packets in LSP's, TDI filters and NDIS IM ... thus you don't know that there was an attempt to send packet. ... Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/ ...
    (microsoft.public.win32.programmer.kernel)
  • Re: DHCP issue switching scopes
    ... Here is a text file dump of a discover/offer packet pair ... I can send the entire capture file ... Time since reference or first frame: ... User Datagram Protocol, Src Port: bootps, Dst Port: ...
    (microsoft.public.windows.server.networking)