Many current routers have enabled support for ReadySHARE printers, and this support involves sending out 255.255.255.255 broadcasts that are viewed by the Linux kernel as martians. The problem is that these broadcasts are made at 3-second intervals, and are flooding the syslog because we ship /etc/sysctl.conf with net.ipv4.conf.all.log_martians=1 The logging is of dubious value, especially for newbies, but the downside of filling up /var/log is pretty unattractive. Netgear routers in particular have no way to disable ReadySHARE. This may be true of others as well, but Netgear has enough market share to make this a problem. We should consider disabling log_martians to prevent this. Reproducible: Steps to Reproduce:
BTW Colin, we would need to handle /etc/sysctl.conf -> /usr/lib/sysctl.d/00-system.conf Maybe a %triggerpreun on older initscripts that would do the rename prior installing new 00-system.conf
CC: (none) => thierry.vignaudAssignee: bugsquad => mageiaSource RPM: basesystem => initscripts
Hmm, /etc/sysctl.conf should still be used AFAIK. I'm not sure we need to change it right now? If we do, I would recommend a /etc/sysctl.d/01-mageia.conf (as nothing at runtime should alter/edit /usr/lib/sysctl.d/00-system.conf which should not be edited). There was some discussion recently about the inheritance of those files tho'... I'll dig out the reference so we understand it correctly before we change something. Do we have drak* tools to read/write it? I don't see any reference in our drakxtools code, but it may be hiding elsewhere :)
I suspect this might be the same issue as reported in https://bugzilla.redhat.com/show_bug.cgi?id=924433. I really would like to pull in http://cgit.freedesktop.org/systemd/systemd/commit/?id=fabe5c0e5fce730aa66e10a9c4f9fdd443d7aeda but when I last tried it failed due to a lot of context changes. I should try again as it's quite an annoying bug. (note to self also grab http://cgit.freedesktop.org/systemd/systemd/commit/?id=6f6fad96addf6b00b55c98cc0d0d8026b0c1e7ca)
See Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=924433
Comment #1 is really a separate issue from this bug. net.ipv4.conf.all.log_martians doesn't appear in /usr/lib/sysctl.d/00-system.conf so I don't see a problem with setting it to 0 in /etc/sysctl.conf. I could do that unless someone objects, although when I test it, it doesn't seem to actually make a difference. Whether it's =0 or =1, it's always net.ipv4.conf.all.log_martians=0 once the system boots (the same is true with net.ipv4.conf.all.rp_filter as well (at least); it's always =0 after boot, no matter how it's set in /etc/sysctl.conf). And I'm not even sure this would make a difference since the specific entries for the Internet devices, such as net.ipv4.conf.eth0.log_martians, are =1.
CC: (none) => dan
I did a bit more testing, and I'm not able to actually make the log_martians=0 settings stick to the interfaces. Just adding these lines to /etc/sysctl.conf net.ipv4.conf.all.log_martians=0 net.ipv4.conf.default.log_martians=0 doesn't do it--the specific interfaces all still end up with it enabled after boot, e.g. $ sysctl -a |grep eth0.log_m net.ipv4.conf.eth0.log_martians = 1 I tried adding a second systemd unit to call systemd-sysctl a second time during boot, and didn't completely solve the problem. I tried After=network.target, Before=network.service, Before=systemd-udevd.service and After=shorewall.service and only the latter made a bit of difference (indicating that shorewall seems to be messing with the settings somehow). That second sysctl setting in the latter case actually caused the system to end up with net.ipv4.conf.all.log_martians=0 net.ipv4.conf.default.log_martians=0 after boot, but the configurations for the specific interfaces still end up =1. I suspect this problem has to do with the network devices being initialized with the (presumably) default log_martians=1 settings in effect, before sysctl even has a chance to change them. If that's so, then it will take a kernel patch to disable this logging by default, or manual intervention in adding all the desired interfaces to /etc/sysctl.conf.
This bug report stalled two years ago. Is it still valid? Should we revive it?
Keywords: (none) => NEEDINFO
In use of journalctl once we switched to systemd I haven't noticed any martian messages, so I'm guessing the problem was resolved with systemd development. Closing.
Status: NEW => RESOLVEDResolution: (none) => FIXED