I'd be browsing dumb, fat and happy when all of a sudden the next URL I clicked on failed to display. "Server not found", or some such message.
I opened a Konsole and pinged Google.com. Nothing.
I did "cat /etc/resolv.conf" and noticed that my ISP DNS server information had been replaced with "192.168.1.1", as if it was being reconfigured as a static IP. My wicd icon in the system tray still showed a vertical green bar, indicating my connection was good. I opened up the wicd dialog and disconnected and reconnected to my wireless router. I got another green bar and fired up my browser. It still wouldn't connect. I checked resolv.conf and noticed that redoing my connection did NOT reload resolv.conf.
I disconnected my wireless connection and went to my cable modem/wireless power strip and recycled the power to both of them. When my wireless was back up I used wicd to reconnect. I could browse again. I didn't want to be doing that every time my connection got dropped.
A similar bug, reported here didn't offer helpful information. I do not want to disable the automatic assignments to /etc/resolv.conf because I may be wanting to access another AP.
Some bug reports say that installing resolvconf prevents the resolv.conf file from being overwritten, but I didn't want to install it for reason expressed below.
This was the beginning of a month of involuntary wireless disconnects that occurred with increasing frequency. When a drop occurred just minutes after turning on my equipment last week, and about once and hour there after, I was beginning to suspect my Linksys WRT54GL router. I purchased a new TP-Link TL-W1043ND wireless (thanks for the tip, SithLord48!), expecting the problem to go away. Then, last Friday, while composing a response to a problem on this forum, I happened to be looking at the cable modem while deep in thought when the lights on the front of it all turned off, then started blinking just as if it had been power cycled! "Ah ha!, I got you!", I thought. I called my ISP tech support staff and their logs verified several incidents of involuntary power cycling on their side. They told me to bring in my modem and get it exchanged for a new one. I did.
Fully expecting the issue to be resolved I began surfing. Nothing happened that night, but on Saturday, the next day, I got another disconnect. Resolv.conf contained only 192.168.1.1. I had created a copy of that file containing my DNS values and copied it on top of resolv.conf. I pinged Google.com and got a response!. Browsing resumed, but during the day Friday I got several more disconnects, and on a couple occasions, even though wicd's icon had a green bar, and I restored resolv.conf, pinging google.com gave no response.
New wireless router. New modem. What could it be? FireFox? This morning I began surfing with Konqueror. Five minutes after I began surfing I got a disconnect. I immediately opened a console and restored resolv.conf from my backup. Surfing resumed normally.
It's not FireFox and, it's not Konqueror. It's not my wireless router. It's not my modem.
So, I will focus on either the wireless hardware in my laptop (Link 1500) or the wicd or dhcp application.
If it's wicd an update will fix it sooner or later.
I wondered if the default lease time had somehow been reconfigured in a recent update. I checked my wireless router but found the lease time is still 1440 minutes (24 hours). While I had the admin section of my wireless router opened I add my ISP DNS numbers and domain to the DHCP settings of the wireless and rebooted it, then continued to research the problem.
dhclient.conf has no active settings for the lease time. That which it does have is commented out.
Manually setting the DNS, search and domain in resolv.conf doesn't work, even if you mark the file read-only, because /sbin/dhclient-script changes the owner and chmod's it, then overwrites it with "$new_resolv_conf" which, I believe, is the source of the problem:
That's why people who try to fix this problem report that their "fixed" changes to resolv.conf do not stick. I could modify that code with:
but I'd have no guarantee that my changes wouldn't be overwritten with a future update.
Putting my ISP DNS and domain name in my TP-Link wireless router DHCP settings appears to be working. IF I use my laptop to connect to public wireless or at Starbucks or a friends house I haven't changed dhcp3 so it should get me connected, and to stay connected I may have to make a copy of my resolv.conf as resolv.conf_whereever and use the cp command to cp it to resolv.conf if resolv.conf gets reset to the gateway.
Someone suggested adding
to /etc/dhclient-enter-hooks but that would require you to manually edit resolv.conf and insert the DNS IP and domain and search names, IF you have that information. If you are at Starbucks and you don't know their DNS you'll have to use OpenDNS or Google's DNS, IF you've kept those settings handy in a file somewhere.
Meanwhile, I am going to keep an eye on this. IF putting the DNS and domain name in the router configuratin works I'll just leave it this way for now.
I opened a Konsole and pinged Google.com. Nothing.
I did "cat /etc/resolv.conf" and noticed that my ISP DNS server information had been replaced with "192.168.1.1", as if it was being reconfigured as a static IP. My wicd icon in the system tray still showed a vertical green bar, indicating my connection was good. I opened up the wicd dialog and disconnected and reconnected to my wireless router. I got another green bar and fired up my browser. It still wouldn't connect. I checked resolv.conf and noticed that redoing my connection did NOT reload resolv.conf.
I disconnected my wireless connection and went to my cable modem/wireless power strip and recycled the power to both of them. When my wireless was back up I used wicd to reconnect. I could browse again. I didn't want to be doing that every time my connection got dropped.
A similar bug, reported here didn't offer helpful information. I do not want to disable the automatic assignments to /etc/resolv.conf because I may be wanting to access another AP.
Some bug reports say that installing resolvconf prevents the resolv.conf file from being overwritten, but I didn't want to install it for reason expressed below.
This was the beginning of a month of involuntary wireless disconnects that occurred with increasing frequency. When a drop occurred just minutes after turning on my equipment last week, and about once and hour there after, I was beginning to suspect my Linksys WRT54GL router. I purchased a new TP-Link TL-W1043ND wireless (thanks for the tip, SithLord48!), expecting the problem to go away. Then, last Friday, while composing a response to a problem on this forum, I happened to be looking at the cable modem while deep in thought when the lights on the front of it all turned off, then started blinking just as if it had been power cycled! "Ah ha!, I got you!", I thought. I called my ISP tech support staff and their logs verified several incidents of involuntary power cycling on their side. They told me to bring in my modem and get it exchanged for a new one. I did.
Fully expecting the issue to be resolved I began surfing. Nothing happened that night, but on Saturday, the next day, I got another disconnect. Resolv.conf contained only 192.168.1.1. I had created a copy of that file containing my DNS values and copied it on top of resolv.conf. I pinged Google.com and got a response!. Browsing resumed, but during the day Friday I got several more disconnects, and on a couple occasions, even though wicd's icon had a green bar, and I restored resolv.conf, pinging google.com gave no response.
New wireless router. New modem. What could it be? FireFox? This morning I began surfing with Konqueror. Five minutes after I began surfing I got a disconnect. I immediately opened a console and restored resolv.conf from my backup. Surfing resumed normally.
It's not FireFox and, it's not Konqueror. It's not my wireless router. It's not my modem.
So, I will focus on either the wireless hardware in my laptop (Link 1500) or the wicd or dhcp application.
If it's wicd an update will fix it sooner or later.
I wondered if the default lease time had somehow been reconfigured in a recent update. I checked my wireless router but found the lease time is still 1440 minutes (24 hours). While I had the admin section of my wireless router opened I add my ISP DNS numbers and domain to the DHCP settings of the wireless and rebooted it, then continued to research the problem.
dhclient.conf has no active settings for the lease time. That which it does have is commented out.
Manually setting the DNS, search and domain in resolv.conf doesn't work, even if you mark the file read-only, because /sbin/dhclient-script changes the owner and chmod's it, then overwrites it with "$new_resolv_conf" which, I believe, is the source of the problem:
Code:
chown --reference=/etc/resolv.conf $new_resolv_conf
chmod --reference=/etc/resolv.conf $new_resolv_conf
mv -f $new_resolv_conf /etc/resolv.conf
Code:
if ! $(egrep -q "192.168.1.1" $new_resolv_conf); then
chown --reference=/etc/resolv.conf $new_resolv_conf
chmod --reference=/etc/resolv.conf $new_resolv_conf
mv -f $new_resolv_conf /etc/resolv.conf
fi
Putting my ISP DNS and domain name in my TP-Link wireless router DHCP settings appears to be working. IF I use my laptop to connect to public wireless or at Starbucks or a friends house I haven't changed dhcp3 so it should get me connected, and to stay connected I may have to make a copy of my resolv.conf as resolv.conf_whereever and use the cp command to cp it to resolv.conf if resolv.conf gets reset to the gateway.
Someone suggested adding
Code:
make_resolv_conf() {
echo "doing nothing to resolv.conf"
}
Meanwhile, I am going to keep an eye on this. IF putting the DNS and domain name in the router configuratin works I'll just leave it this way for now.
Comment