On Wednesday 12 December 2007, Allen Weiner wrote: > On Wed, 2007-12-12 at 10:50 -0500, Chris Knadle wrote: > > The short answer: not simple. I gave you a vague idea of the types of > > tools used to try to figure that out to answer the questions: What ports > > are open, what processes are associated with those ports, what network > > traffic is passing through the box. > > Chris: Thanks very much for your continued participation in this > thread. Thanks also to PorkChop and Mike Kershaw for their input. > > I did read what you wrote about TCPDUMP, packet sniffing, etc. I have at > one time browsed the OReilly book, "Network Troubleshooting Tools".
I took a quick look at a synopsis of what that book covers. Please note that the packet sniffer 'Ethereal' has been renamed to 'Wireshark'. > > > Hopefully, this doesn't matter, but I used kedit to make the changes to > > > resolv.conf. This leaves around a backup file. > > > > Almost all text editors can be configured to leave a backup file, or > > configured not to. > > "Bit Twister" from comp.os.linux.networking wanted me to remove all > backup files. So I thought there might be side-effects from having them > around. Nope. DNS requests read /etc/resolv.conf every time, so the backup files won't get used. I just proved that for myself again with strace. > Yesterday Dec. 11 I ran for over 3 hours with my original resolv.conf. > There was not a single UDP packet to port 137 logged by iptables. > > Today, I changed resolv.conf back to the contents that were previously > associated with the UDP packets to port 137. > > I let the system run for 10 minutes. During that time, there were no > "events" reported by Firestarter. I then rebooted. My system resumed the > behavior I've previously described: every 30 seconds, Firestarter is > reporting logging of UDP packets to port 137. According to Firestarter, > there is a one-to-one correspondence between connection attempts to port > 80, and the "Samba" packets. Hmm. So you're saying there's a direct link between TCP packets on port 80 and UDP packets on port 137. Think about that for a minute. It doesn't make sense. I don't doubt that you're seeing this behavior, but there's no simple way to explain it. > I now have a hardcopy of the script which implements "service network > start/stop/restart". The networking scripts are easier to decipher from > hardcopy than from the screen. (I own an inkjet printer, a gift from a > friend, but I never bought cartridges for it.). "service network stop" > invokes ifdown-eth. I have the hardcopy for ifdown-eth. I can understand > the Bash, but I don't understand what the code is doing. I'm assuming you mean that certain external programs are called and that you don't know what those do. With the 'file' command you can find out what type of file a file is; for instance 'file /sbin/ifup' reports that /sbin/ifup is an ELF 32-bit LSB executable -- that means that it's a binary file that's not human-readable. Often you can find a man page to explain what these binary files do and what parameters are available. Hope that helps. -- Chris -- Chris Knadle [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Dec 5 - Open Source Show and Tell Jan 2 - TBD Feb 6 - DBUS Mar 5 - Setting up a platform-independent home/small office network using Linux
