DJA wrote:
..I've never used Tcpdump before,
so I'll have to research. Any tips?
I like to capture data to a file with tcpdump, and use the nice gui
program ethereal to review the data. It is also possible to do it all
from within ethereal. One benefit of tcpdump to file is that the file
can be read and analyzed on some other host.
Perhaps others with experience will chime in on their standard
practices, but here's mine:
tcpdump -nieth0 -s1500 -w /tmp/tcpdump.cap
then sometime later
^C
or if scripting this, run it in the background and kill the process via
cron or at.
I amost _always_ use that the -n option (do not resolve dns), whatever
else I do. See
man tcpdump
for additional explanations and options.
You may need to limit the run time because he output can grow pretty
large!. Filtering can be inserted to limit the chaff. Writing tcpdump
filtering rules is somewhat of an art (and I am still a novice, there),
but sample rules are
host 192.168.1.1
not host 192.168.1.1
'(ether broadcast or ip broadcast)'
and so on (the default logical connective is 'and', I believe), and in
some cases (eg the broadcast example above), it seems a connective
*must* be used or you get a syntax error.
If this is expected to take a while to find the evidence, I would think
some kind of loop like {monitor-awhile; terminate/restart with alternate
logfile; if event occurred (based on other other evidence?) save log,
else discard log; repeat;}
..
> As for the
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
line, where is the best place to put this so it gets run at start up?
Yes, indeed. /etc/sysctl.conf. See:
man sysctl.conf
Note that the sysctl var name is what _follows_ the /proc/sys/, namely
net/ipv4/icmp_ignore_bogus_error_responses
Of course, I'd much rather stop the router from sending the error, or
figure out why it can't see the port at the destination. Blocking both
incoming and outgoing ICMP at the firewall (part of the router) has no
affect. The bigger annoyance is that these error messages are spewed to
the console every second or so, making any console unusable.
I know the feeling. I suppose one might diddle syslog.conf (or the
equivalent for syslog-ng) to divert such messages so that they do not
get handled by the standard console-logging rule. But that's still an
ugly & annoying cover-up.
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
