On Mon, 2007-12-03 at 11:50 -0500, Chris Knadle wrote: > On Monday 03 December 2007, Allen Weiner wrote: > > I run Fedora 7 on my desktop PC and use Verizon DSL. My modem is a > > Westell 6100-E90 modem/router. > > When using Google to look up the router, I see that other Fedora 7 users > are having trouble, and that you've posted this query elsewhere.
I just did a quick Google search on "Westell 6100" and Fedora. Nothing popped out other than my own posts to several forums. What Google search terms did you use? (Some of my posts were under the nickname AlFrugal). > Four pages of back-n-forth posts here: > http://www.webservertalk.com/message2132448.html Yes, I had two long threads on comp.os.linux.networking, mostly with "Bit Twister". He was helpful at first, but the interchange deteriorated. Ultimately, he insisted that I change my "hosts" file. Both I and another poster felt the change was unnecessary. > > Two more pages of troubleshooting posts here: > http://fixunix.com/networking/11810-difficulty-recovering-dsl-loss-sync.html > > Seems like you've been working at this problem for a while. :-/ I've been working on this for several months. It's an interesting learning experience, but the problem is irritating. I initially thought the problem was loss of DSL sync, but have since concluded that it isn't. > > > I'd like to pinpoint where "service network restart" hangs. How can I do > > this? > > > > Two approaches come to mind: > > > > 1. Place hooks in the networking scripts that are invoked by "service > > network restart". This approach is unappealing to me. I have no > > experience with BASH scripting. (Although I could keep backups of the > > original scripts.) > > It's time for you to get used to Bash. > Print a copy of the "Advanced Bash Scripting Guide" and read it. > http://tldp.org/LDP/abs/abs-guide.pdf I've downloaded a copy of the "Advanced Bash Scripting Guide" (PDF) and have been reading through it. In one of the above referenced threads, "Bit Twister" posted several interesting scripts which I would like to understand. > > Some distributions have a package for this manual, such as the > package 'abs-guide' on Debian; there might be a similar package for Fedora so > you could look at the guide in HTML. > > After working with the abs-guide, read the Bash man page. There are quite > a few things there that don't appear in the guide. Yes, I know it's long. > > > Mainly the debugging "hooks" I assume you mean would be 'echo' statements > before commands to give some text output of what's about to be run so that > you know what command hangs. That's not that hard. Unless you mean > something else? Yes, I meant putting "echo" statements in the scripts. In one of the above mentioned threads, "Bit Twister" leads me to think this is not so easy for a novice like me. Here's what he said: ****** begin quote ********* Hehe, I spent a day in those 1 or two years ago. What I had to do was create 8 desktops, pretty near each desktop had 3 or 4 terminals up, 1 term following the code, another to see config files, another to hunt down man pages and doucments, .. When a script would call another script, I would open it in another desktop so I could keep drilling down reading code. When I finally hit the bottom of the script, I would go back to the desktop which called the script. Sounds good in theory, takes a very methodical, conscientious person to make that work, and you better damn well know your backups are good. That is why a multi-boot system, with selection to boot a copy of your "Production Install" is handy for screwing with system scripts that could hurt you. :-D ***************** end quote ********************* > > > 2. Issue "service network restart" with "strace" turned on. (I've never > > used strace.) > > strace gives lots of output which generally isn't friendly to read. > Invoking 'strace /etc/init.d/networking restart' gives me 325 lines of > output, which isn't bad. If nothing else you might be able to run it when > things work and when they don't and compare the output. Don't forget to > redirect the stderr output to stdout with 2>&1. > > > Is there an easier and/or better approach? > > You might want to compare the output of 'iptables -L -n' before + after > the > problem; Tauno Voipio indicated that the router was trying to connecto to > your local box on port 80, which is something very unusual, and he was > concerned that your local Fedora 7 firewall would dynamically make rules to > block out the router. > The conclusion I reached from Tauno Voipio's comments is that every 15 seconds, Verizon is probing my modem/router to see if I'm running a server. My daily logwatch report always shows many megabytes worth of packets flagged by iptables. I'd like to check on the Verizon forums of dslreports.com to see if others observe this happening to them. I'll look into your suggestion re issuing the iptables command. I didn't pursue that angle any further previously because the problem doesn't occur following a reboot, even though I'm typically on for many additional hours. > > Not sure what else to suggest at the moment. > > -- Chris > _______________________________________________ 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
