After running a large update and rebooting a few weeks ago, I found that my internet connection had stopped working. My internal network still worked fine though, so it I know it's not the card itself or its configuration.

After a bit of trial and error I discovered that simply running dhclient brings the connection up again, so it appears that something is interfering with the initial dhcp update to my ISP (or something like that; I'm no expert in this area. )

My usual policy in cases like this is to wait through two or three updates in the hopes that it's just a temporary problem, but it's been a while now and subsequent updates haven't fixed it.

I've tried looking around, but I can't come up with search criteria specific enough to narrow it down to my specific situation. I'm not even sure where to begin looking to diagnose the problem, nor do I know which package update(s) could've affected it.

Any suggestions?

I'm not sure what might be useful, but here's the relevant entry in /etc/network/interfaces. I have it configured with a static internal address, with my router as the gateway.

I don't get what the problem is, you are saying you use dhclient (which implies a DHCP configuration) but your interface configuration points to being a static IP.

Is your intention to have a static IP address on your PC? Is the case that after starting up the computer you will be at a desktop with no internet access? What is the gateway, a home router, in which case my thoughts would run to an IP conflict since it is most likely also doing DHCP in that range.

Also your IP configuration seems a bit off, did you manually set the MTU and the other additional options?

Can you try to boot up in a debian based live distro? ie. try grml or sidux, and see how they are configured. They should be able to run out of the box without reconfiguring.

Sorry if I was unclear here. I'm not really clear on the proper terminology to use. Up until recently everything always got configured automatically and I never had any problem like this (nothing that wasn't related to the underlying card configuration itself at least).

To attempt to make it clearer, I have two desktops, and they are both connected to my router (wired), which is in turn connected to my cable internet box. The router also allows local networking between the systems. I've statically set their respective addresses to 192.168.1.2 and 192.168.1.3 (on the systems themselves and in the router settings), so that they remain constant on my LAN, but the router uses dhcp to configure its connection to my ISP.

All I really know is that ever since I ran an update on system 2 a few weeks ago, it has failed to establish a connection to my ISP on boot-up. Even pinging well-known sites like google.com returns unknown host errors. The local network, including the nfs shares between the two systems, is not effected and works right from the start.

After I run dhclient on the system, the internet connection works also.

System 1 is as yet unaffected by all this and connects just fine. I've held back on running any updates on it since this problem started.

I suppose then that it's more accurate to say that system 2 is unable to automatically establish a connection through my router's gateway address, or something like that. Why dhclient makes it work, I have no idea. This is beyond my previous experience.

As for my local settings, yes, I set it all up myself a few years ago, according to info gained on the net. Honestly, I'm still not sure I understand all of it, but it's worked just fine up till now. What I read said that increasing the mtu should help speed up the LAN. The maximum mtu thing I discovered through trial-and-error; it's an onboard card and it simply won't accept any value higher than that.

For diagnostic purposes, please post the output of
(75.126.162.205 is linuxquestions.org)

It sounds like you are missing DNS in /etc/resolv.conf and running dhclient will pull it from the router. Try adding the following line to your network configuration file:

dns-nameservers 192.168.1.1 x.x.x.x

You can replace x.x.x.x with DNS servers you have from you ISP if you know them.

1 members found this post helpful.

Thanks for the responses. My resolv.conf looks like this. zaq is the domain of my ISP.
The resolv.conf on my other, working machine simply has this:
route -n shows this. But of course this is after everything is up and working.
Ping and traceroute probably won't show anything unusual unless I reboot and lose the connection again. As I said, everything's fine once I run dhclient.

By "network configuration file" you mean /etc/network/interfaces, right? I'll give it a try, but of course it means I'll have to reboot to see if it works.

I don't know what my primary DNS address would be. It doesn't seem to be listed anywhere in my router settings, so I believe it's set to negotiate it automatically. It's kind of hard to tell for sure though, since the setup interface is all in Japanese.

Well, that seems to have done the trick. I added dns-nameservers 192.168.1.1 to my /etc/network/interfaces and rebooted, and it appears to be working again.

I also compared my interface settings to the ones on my other system (which is a bit newer and less crufty), and I saw that it doesn't have a "mapping" section in it. So I assume it was unnecessary and removed it.

My resolv.conf now only shows nameserver 192.168.1.1, which I guess indicates that it's grabbing the address correctly now. I'm assuming it was dhclient that was searching the ISP domain and adding the extra lines.

I'm still curious about what changed that caused it to break, but I suppose it really doesn't matter. It made me clean up my settings a bit in any case.

So unless you see anything else I should worry about, I'm going to call this resolved. Thanks again!