Could need some help to understand logMessage
Hello List, seeing my Windows Firewall (ZoneAlarm) going crazy because of a PingScan, I switched to my Linux PC (SuSE 7.1) and startet ethereal to see whats goging one. Seeing tons of ICMP Echo request packages I took a look at my /var/log/messages (which has grown up to 8 MB so far) and I found the following entries (all the same, each second for about 18 min) Jun 4 16:01:36 <myHost> kernel: martian source 0b6edec3 for ff6edec3, dev eth0 Jun 4 16:01:36 <myHost> kernel: ll header: ff ff ff ff ff ff 00 08 c7 ea 7b 85 08 00 And about every minute this: Jun 4 16:02:10 <myHost> scanlogd: <otherIP> to <myIP> ports 47557, 699, 1059, 387, 714, 1014, 654, ..., fSrpauxy, TOS 00, TTL 46 @16:02:10 (myIP and otherIP are public IPs) Still learing about how networks work, I understand 80% of whats going on here. But what does the "martian source" source mean? Could anyone give me a hint, please? Thank you very much. Regards, phil
Hi Phil! As someone already explained on this list: What does "kernel: martian source aabbccdd for 11223344, dev eth0" mean? These are packets that Linux does not expect from the direction they came from (i.e. packets from internal hosts coming in on the external interface). The cause is probably a misconfigured machine on your LAN. You can turn off logging those packets via /proc/sys/net/ipv4/conf/*interface*/log_martians which is documented in /usr/src/linux/Documentation/proc.txt (found on: http://members.cotse.com/nix/susesecurity/faq/ and on this list!) Phil Schrettenbrunner wrote:
. . .
Jun 4 16:01:36 <myHost> kernel: martian source 0b6edec3 for ff6edec3, dev eth0 Jun 4 16:01:36 <myHost> kernel: ll header: ff ff ff ff ff ff 00 08 c7 ea 7b 85 08 00
. . . HTH -- best greetings from Solingen /GERMANY Dieter Hürten
Hi Phil and Dieter
As someone already explained on this list:
What does "kernel: martian source aabbccdd for 11223344, dev eth0" mean?
These are packets that Linux does not expect from the direction they came from (i.e. packets from internal hosts coming in on the external interface). The cause is probably a misconfigured machine on your LAN. You can turn off logging those packets via /proc/sys/net/ipv4/conf/*interface*/log_martians which is documented in /usr/src/linux/Documentation/proc.txt
...or you have got no default route to your ISP's IP, especially if you have a PPP connection to the ISP. IPPP seems to drop default routes if you do not place a '-defaultroute' in /etc/ppp/options.ippp0 (I found this out the hard way this weekend. Perhaps the normal PPPD does the same?) Bye, Jürgen
* J. Mell wrote on Mon, Jun 04, 2001 at 18:27 +0200:
...or you have got no default route to your ISP's IP, especially if you have a PPP connection to the ISP. IPPP seems to drop default routes if you do not place a '-defaultroute' in /etc/ppp/options.ippp0
I'm sure that ipppd will not replace existing default routes, from /var/log/messages: May 17 11:28:00 dx ipppd[1407]: ppp not replacing existing default route to ippp6[0.0.0.0] But please note, the SuSE ip-up script is not able to handle real routing. You must have only a default route when useing ipppX devices. ip-up don't cares about /etc/route.conf at all (at least up to SuSE 7.0). I wrote multiple messages about it, to feedback@suse too, but AFAIK it's still the situation. I have an ip-up version which is able to handle real routing and I have an article about it on http://sws.dett.de/ --> Search "ip-up routing" or similar, I don't remember the URL. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Monday, 4. Juni 2001 22:27 you wrote:
* J. Mell wrote on Mon, Jun 04, 2001 at 18:27 +0200:
...or you have got no default route to your ISP's IP, especially if you have a PPP connection to the ISP. IPPP seems to drop default routes if you do not place a '-defaultroute' in /etc/ppp/options.ippp0
I'm sure that ipppd will not replace existing default routes, from /var/log/messages:
May 17 11:28:00 dx ipppd[1407]: ppp not replacing existing default route to ippp6[0.0.0.0]
This happens, if there is a 'defaultroute' statement in /etc/ppp/options.ippp0 and no 'deldefaultroute'. Unfortunately something must have changed from SuSE 6.3 to 7.1: If there is no 'defaultroute' statement in /etc/ppp/options.ippp0, a previuosly set default route (from /etc/route.conf) will be deleted - at least sometimes (I could not reproduce the conditions when and why the route was deleted.) This resulted in the first connection to our ISP to work correctly but afterwords (we have a dial-up line to the ISP) I got lots of Martian packets due to the missing route. I fixed this with a '-defaultroute' statement in /etc/ppp/options.ippp0 and now everything is fine, as the route set from /etc/route.conf stays active. Bye, Jürgen
* Jürgen Mell wrote on Tue, Jun 05, 2001 at 11:54 +0200:
Unfortunately something must have changed from SuSE 6.3 to 7.1: If there is no 'defaultroute' statement in /etc/ppp/options.ippp0, a previuosly set default route (from /etc/route.conf) will be deleted
SuSE's ip-down script does this by ifconfig $INTERFACE down ; ifconfig $INTERFACE up which clears all routes through $INTERFACE. SuSE's ip-up just sets a default route to the device ($INTERFACE) what's going up - and doesn't cares if you specified a default route in /etc/route.conf or not. ip-up/down dont even read route.conf.
- at least sometimes (I could not reproduce the conditions when and why the route was deleted.) This resulted in the first connection to our ISP to work correctly
Yep, this sounds like such a ip-up/down problem: first works, but second not. That's why I patched that thing and integrated full route.conf support to it. If you have more that a single ipppX device and/or a route different from exactly a defaultroute through that single device, you cannot use SuSE's ip-up (at least up to SuSE 7.0, haven't checked 7.1). It will simply not work.
but afterwords (we have a dial-up line to the ISP) I got lots of Martian packets due to the missing route. I fixed this with a '-defaultroute' statement in /etc/ppp/options.ippp0 and now everything is fine,
Yep, if you use SuSE's ip-up script, it sets a deaultroute hardcoded without any checking. If you configured ipppd to set up a route too - maybe a changed default value - you might get such results. By that, IIRC, SuSEs ip-up script dont reports such errors (correct: it reports it via STDOUT/STDERR which are closed since the script has no controlling terminal).
as the route set from /etc/route.conf stays active.
Not from route.conf. You can make a simple test: remove (comment out) the default route from route.conf (when offline) and give a "isdnctrl dial ippp0". I expect you will have a defaultroute through ippp0. After all, I would suggest to let ipppd set the defaultroute, and not ip-up since ipppd is a lot more clever at this. But you cannot use SuSEs version of ip-up for this - since it doesn't read route.conf at all IIRC. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Monday 04 June 2001 16:30, Phil Schrettenbrunner wrote:
Hello List,
seeing my Windows Firewall (ZoneAlarm) going crazy because of a PingScan, I switched to my Linux PC (SuSE 7.1) and startet ethereal to see whats goging one. Seeing tons of ICMP Echo request packages I took a look at my /var/log/messages (which has grown up to 8 MB so far) and I found the following entries (all the same, each second for about 18 min)
Jun 4 16:01:36 <myHost> kernel: martian source 0b6edec3 for ff6edec3, dev eth0 Jun 4 16:01:36 <myHost> kernel: ll header: ff ff ff ff ff ff 00 08 c7 ea 7b 85 08 00
[if i'm not mistaken] "Martian source" means the kernel received a packet that, according to routing table / netmask, cannot legally arrive there. This would happen, for instance, if you configured your network for 192.168.x.x and a packet claiming to be from 10.x.x.x arrived there, etc. Thus; a sanity-check. However, it is difficult to read because the IPnumbers are notated in hex and (for PC architectures) reversed as well. Decode as follows: Split the number in four 2digit pairs, then convert from hex to decimal: 0b => 11, 6e => 110, de => 222, c3 => 195 then reverse and add the dots: => 195.222.110.11 etc. So, the message reads something like: "Unexpected, illegal packet claiming to be from 195.222.110.11 destined for 195.222.110.255 detected on eth0." Whether someone is trying nasty stuff or it is just a misconfiguration I cannot tell because I don't know what your IP number REALLY is. Maybe someone just made a typo while configuring something. Maarten
participants (6)
-
Dieter Huerten -
J. Mell -
Jürgen Mell
-
Maarten van den Berg -
Phil Schrettenbrunner -
Steffen Dettmer