Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

wrc1944 · 2010-02-04 10:31:41

Suddenly, after a pacman -Syu 2 days ago, on reboot today, I can't get a wired network connection with Arch.
This box has 7 other distros on it, all of which work perfectly. Just a simple cable modem and linksys wireless router, which also works fine on another box in the house (wireless, with 4 distros). The main wired box is linked by an ethernet cable from a port on the router.

So, all hardware and all other distros are working fine- it has to be that something has changed in the Arch default configs during the updates, but I can't seem to find it. This arch install is current, and has been woking fine for years. I did nothing but the regular -Syu update, and on next boot I have no connection, although I'm getting a lease (for 0.0.0.0 ???) , but it says the interface is invalid. It acknowledges eth0 from 192.168.1.1, which is correct

Figured it had to be the dhcpcd version, so I tried downgrading dhcpcd to the last working version- no luck. Reset modem and router many times, no luck. Removed the dhcpcd PID file each time, still no luck. Googled around for 3 hours, no luck. All the other distros connect on boot, normally.

Here's a few examples of the output when I try from command line.

[root@myhost wrc]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:19:66:A1:B4:8D  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3130 (3.0 Kb)  TX bytes:1704 (1.6 Kb)
          Interrupt:25 Base address:0xc000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1200 (1.1 Kb)  TX bytes:1200 (1.1 Kb)

[root@myhost wrc]# dhcpcd eth0 up
dhcpcd: version 5.1.4 starting
dhcpcd: up: interface not found or invalid
dhcpcd: eth0: rebinding lease of 0.0.0.0
dhcpcd: eth0: acknowledged from 192.168.1.1
dhcpcd: eth0: leased 0.0.0.0 for 172800 seconds
dhcpcd: eth0: add_route: No such process
dhcpcd: forking to background

[root@myhost wrc]# dhcpcd eth0
dhcpcd: version 5.1.3 starting
dhcpcd: eth0: rebinding lease of 0.0.0.0
dhcpcd: eth0: acknowledged from 192.168.1.1
dhcpcd: eth0: leased 0.0.0.0 for 172800 seconds
dhcpcd: eth0: add_route: No such process
dhcpcd: forking to background

[root@myhost wrc]# dhcpcd eth0
dhcpcd: version 5.1.4 starting
dhcpcd: eth0: rebinding lease of 0.0.0.0
dhcpcd: eth0: acknowledged from 192.168.1.1
dhcpcd: eth0: leased 0.0.0.0 for 172800 seconds
dhcpcd: eth0: add_route: No such process
dhcpcd: forking to background

Last edited by wrc1944 (2010-02-07 16:43:41)

wrc1944 · 2010-02-04 20:20:29

UPDATE:
Now get this, after hours of struggling around:

[root@myhost wrc]# dhcpcd --release eth0
dhcpcd: sending signal 1 to pid 2494
dhcpcd: waiting for pid 2494 to exit
[root@myhost wrc]# /etc/rc.d/network restart
:: Stopping Network                                                                                      [DONE]
:: Starting Network                                                                                      [DONE]
[root@myhost wrc]# dhcpcd eth0
dhcpcd: dhcpcd already running on pid 2587 (/var/run/dhcpcd-eth0.pid)
[root@myhost wrc]# dhcpcd --release eth0
dhcpcd: sending signal 1 to pid 2587
dhcpcd: waiting for pid 2587 to exit
[root@myhost wrc]# dhcpcd eth0
dhcpcd: version 5.1.5 starting
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: offered 192.168.1.100 from 192.168.1.2 `'
dhcpcd: eth0: ignoring offer of 192.168.1.100 from 192.168.1.1
dhcpcd: timed out
[root@myhost wrc]#

Set gateway in rc.conf, and got this:

[root@myhost wrc]# dhcpcd --release eth0
dhcpcd: dhcpcd not running
[root@myhost wrc]# dhcpcd eth0
dhcpcd: version 5.1.5 starting
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: offered 192.168.1.100 from 192.168.1.2 `'
dhcpcd: eth0: acknowledged 192.168.1.100 from 192.168.1.2 `'
dhcpcd: eth0: checking for 192.168.1.100
dhcpcd: eth0: leased 192.168.1.100 for 7200 seconds
dhcpcd: eth0: MTU set to 576
dhcpcd: forking to background
[root@myhost wrc]#

192.168.1.2 is a second wireless only router in another part of the house, bridged to the main linksys router running the Arch and other distro installations, where I have another wireless system, that works fine. (The wired box has no wireless adapter, so it shouldn't even be seeing this).The nameserver in /etc/resolv.conf was 198.169.1.2, so I changed it to 192.168.1.1, and added the gateway to rc.conf.
Now I get this, which is the correct addresses (this is exactly what every other distro reports, but still there is no connection in Arch).:

[root@myhost wrc]# dhcpcd --release eth0
dhcpcd: sending signal 1 to pid 2868
dhcpcd: waiting for pid 2868 to exit
[root@myhost wrc]# dhcpcd eth0
dhcpcd: version 5.1.5 starting
dhcpcd: eth0: broadcasting for a lease
dhcpcd: eth0: offered 192.168.1.100 from 192.168.1.1
dhcpcd: eth0: acknowledged 192.168.1.100 from 192.168.1.1
dhcpcd: eth0: checking for 192.168.1.100
dhcpcd: eth0: leased 192.168.1.100 for 172800 seconds
dhcpcd: forking to background
[root@myhost wrc]#

Here's the current rc.conf section (I've been trying many configs. all failing to get even this far). Still no connection up, even thought it looks good with this output:

HOSTNAME="myhost"

lo="lo 127.0.0.1"
eth0="dhcp"
INTERFACES=(lo eth0)
gateway="default gw 192.168.1.1"
ROUTES=(gateway)

AMAZING- suddenly connected when I opened konqueror! Also survives a logout of kde into gnome. kde problems are blocking my -Syu updates, so I'm in gnome right now, and may have to remove some/all of kde. This has been a ridiculous 2 days on Arch. Still not sure if the connectiion is solved- will find out after a reboot- hope resolv.conf doesn't get overwritten.

Anyone got some ideas on what's going on here and what caused it?

Last edited by wrc1944 (2010-02-04 20:21:42)

raf_kig · 2010-02-04 20:30:27

can you post the output of

route

, preferably after a clean reboot, so that nothing else alters it besides your default config?

wrc1944 · 2010-02-04 20:52:20

raf_kig,
Thanks for the reply!
Here's what route currently says:

[root@myhost wrc]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     202    0        0 eth0
default         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
[root@myhost wrc]#

Can't figure out where the Destination 192.168.1.0 is coming from- never seen it before in years on this setup, with countless distros, both wired and wireless. However, as long as it works, I can't complain.
Don't want to reboot now, as I'm doing a big -Syu (after removing all of kde-4.3.4 and deps), which includes a nice new kde SC 4.4 RC3 (4.3.98) updates. I have RC3 on Gentoo and mandriva (been doing kde svn all along), so I'm really looking forward to the Arch rendition!

wrc1944 · 2010-02-05 02:44:21

OK- my eth0 connection survived a reboot, but the /etc/resolv.conf file was indeed overwritten, as expected. The nameserver 192.168.1.1 I had edited in right before the connection came up last time was replaced by :

# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
domain at.cox.net
nameserver 68.105.28.11
nameserver 68.105.29.11
nameserver 68.105.28.12
# /etc/resolv.conf.tail can replace this line

This configuration is the correct domain and server dns addresses, so of course it should work OK. What's curious is that this is exactly what I had in there before, for years, and then it suddenly didn't work as of Feb2 updates.

As mentioned in post above, I had to add the nameserver 192.168.1.1, which actually is the address of the main linksys router. which is wired to my main computer, and Arch in order to get a connection when konqueror was up.

I still can't understand why it needed nameserver 192.168.1.1 before, and now it doesn't?

I did go ahead and do the -Syu updates, which included a new kernel as well as a somwhat minimal KDE 4.4 SC RC3 install (lacking many packages like konqueror, dolphin, konsole, etc.) Forgot to mention that I had previously update dhcpcd to 5.1.5, and that didn't help at all.

I guess the bottom line is it seems to be worked out at this point- not sure why. If it survives 2-3 more reboots I'll mark this solved.

wrc1944 · 2010-02-05 18:30:26

Well, still having problems with this.

My rc.conf network settings:

HOSTNAME="myhost"

lo="lo 127.0.0.1"
eth0="dhcp"
INTERFACES=(lo eth0)
gateway="default gw 192.168.1.1"
ROUTES=(gateway)

After the first reboot yesterday mentioned before, this was the rewritten resolv.conf file, which had removed nameserver 192.168.1.1, and the connection worked:

# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
domain at.cox.net
nameserver 68.105.28.11
nameserver 68.105.29.11
nameserver 68.105.28.12
# /etc/resolv.conf.tail can replace this line

After today's reboot, resolv.conf was again overwritten, adding nameserver 192.168.1.2, like this:

# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
nameserver 192.168.1.2
# /etc/resolv.conf.tail can replace this line

The connection was disabled, and my ISP's dns addresses had also been removed from resolv.conf.
192.168.1.2 is the address of the T-Link bridged wireless router, which has nothing to do with the wired link from a port on the main linksys router, which runs Arch on a wired box.

Changing the resolv.conf address to 192.168.1.1 (the correct gateway) immediately brings up the connection again when opening a browser, even without adding back in the ISP nameserver addresses.

I guess my question is how can I prevent resolv.conf from being overwritten with the other wireless T-Link router's address? This seems to be the main problem causing this. I'd really hate having to edit resolv.conf every reboot.

I thought specifying the gateway 192.168.1.1 in rc.conf would accomplish this, but apparently not. I'm running 5 other distros on this same hard disk, and none of them ever did something like this- in fact they have always been trouble free for network connections through the linksys wired port via ethernet cable. Very weird that Arch is doing this.

EDIT: Lost the connection again after logging out of Gnome into kde-4.4 RC3- same resolv.conf over-write, back to 192.168.1.2, which causes the connection drop. What is making this happen? Can't that address be "blacklisted somehow?

Here's what route says after I fixed it again, and got the connection back:

[root@myhost wrc]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     202    0        0 eth0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
default         192.168.1.2     0.0.0.0         UG    202    0        0 eth0
[root@myhost wrc]#

What am I missing?

Last edited by wrc1944 (2010-02-05 20:15:47)

sdolim · 2010-02-05 20:18:39

Try using an /etc/dhcpcd.conf file. The "nogateway" option might be what you need to get it to not overwrite resolv.conf. Do "man dhcpcd.conf" to see all the settings you can use -- there's even a way to launch your own script after getting a lease. (I use dhclient rather than dhcpcd, so I don't know for sure if this will work.)

sdolim · 2010-02-05 20:23:52

Also, I noticed that your lease time seems to be pretty short in post #2, only 7200 seconds. So it might be coincidental that it happened when you logged out of gnome; the lease might have expired right around that time (or at 50% of that time, i.e. whenever dhcpcd tries to renew the lease). The new lease caused dhcpcd to overwrite your resolv.conf file again.

wrc1944 · 2010-02-05 20:28:41

sdolim,
Many thanks for your reply! Your suggestion looks very promising. In fact, I was just looking at /etc/dhcpcd.conf, where it has as the only entry

DHCPCD_ARGS="-q"

but I didn't know what that meant.

Man:dhcpcd.conf is definitely my next stop.

EDIT: Sorry the above is wrong- that's /etc/conf.d/dhcpcd

Here's my default /etc/dhcpcd.conf:

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Inform the DHCP server of our hostname for DDNS.
hostname
# To share the DHCP lease across OSX and Windows a ClientID is needed.
# Enabling this may get a different lease than the kernel DHCP client.
# Some upstream DHCP servers may also require a ClientID, such as FRITZ!Box.
#clientid

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
# nohook resolv.conf
nohook lookup-hostname
noipv4ll

Last edited by wrc1944 (2010-02-05 20:43:39)

sdolim · 2010-02-05 20:39:12

The -q flag just tells dhcpcd to be less verbose on the console -- messages are sent to the logs instead.

wrc1944 · 2010-02-05 20:55:58

Added the nogateway option to bottom of /etc/dhcpcd.conf, and rebooted. No luck- resolv.conf was again overwritten with the 192.168.1.2 address. had to changed it again to 192.168.1.1 in order to connect.

Is there something wrong with the other entries in this file? I'll study the man page some more.

route now report this, but after I changed the resolv.conf file- should have checked right after reboot.

[root@myhost wrc]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     202    0        0 eth0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
[root@myhost wrc]#

So my change in resolv.conf after reboot does show up afterwards as the correct default gateway, which of course explains why it then connects.

bagheera · 2010-02-05 21:05:42

How about wicd? I'm using it in all my installations.

http://wiki.archlinux.org/index.php/Wicd

wrc1944 · 2010-02-05 21:33:19

bagheera,
I thought about that, as I'm a huge fan of wicd. I'm using wicd on my other desktop (with 4 linux distros) on the other side of the house, which is by necessity wireless, with the T-Link router bridged from the main linksys router the Arch install is wired to. Had to use the T-Link bridge router to get around serious metallic signal blockages in the line or sight from the linksys- signal was just too weak, even with custom antennas rigged up.

Even if I used wicd on this wired Arch install, that still wouldn't explain why three Gentoo installs, Mandriva, Ubuntu Studio, Pclos, Opensuse, and a countless procession of other distros on this main wired box have always worked with no problems for years, and only Arch (since 3 days ago has presented this problem.

sdolim · 2010-02-05 21:49:45

As I understand it, you have two routers? 192.168.1.1 and 192.168.1.2, correct? Looks like you might be having some DHCP server contention:

dhcpcd: eth0: offered 192.168.1.100 from 192.168.1.2 `'
dhcpcd: eth0: ignoring offer of 192.168.1.100 from 192.168.1.1

From your earlier posts it sounds like you would prefer your box to get its lease from 192.168.1.1.

Try this: go unplug the router that is 192.168.1.2 and then restart dhcpcd. See if it still ignores 192.168.1.1.

You may have to delete the lease files in /var/lib/dhcpcd too.

wrc1944 · 2010-02-05 22:14:28

Correct- the problem is Arch was working before until 3 days ago. I just found this on the net:

etup of OpenDNS and dnsmasq (on Arch Linux)

OpenDNS
1. Stop auto update of /etc/resolv.conf by dhcpcd

dhcpcd is started from /etc/rc.d/network.
/etc/rc.d/network obtains the options of dhcpcd from /etc/conf.d/dhcpcd.
So, I edited /etc/conf.d/dhcpcd like this.

# /etc/conf.d/dhcpcd 
DHCPCD_ARGS="-q --nohook resolv.conf"

2. Edit /etc/resolv.conf

Set OpenDNS server.

# /etc/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220

3. Restart network
etup of OpenDNS and dnsmasq (on Arch Linux)

OpenDNS
1. Stop auto update of /etc/resolv.conf by dhcpcd

dhcpcd is started from /etc/rc.d/network.
/etc/rc.d/network obtains the options of dhcpcd from /etc/conf.d/dhcpcd.
So, I edited /etc/conf.d/dhcpcd like this.

# /etc/conf.d/dhcpcd 
DHCPCD_ARGS="-q --nohook resolv.conf"

2. Edit /etc/resolv.conf

Set OpenDNS server.

# /etc/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220

3. Restart network

$ sudo /etc/rc.d/network restart

I tried step 1., edited resolv.conf, and restarted the network- it didn't work. It removed the correct nameserver 192.168.1.1,
and lost the connection. I re-edited it, and connection came up. Maybe i needed a reboot to make it work.

Turning off the other router permanently is not an option, but I'll try that if the reboot also fails. I'll try step 2 first though.

On Arch, and all the other distros before, IIRC I didn't need the nameservers in resolv.conf, and everything worked automatically.

sdolim · 2010-02-05 22:32:27

One other option to try is to limit your wireless card to only try to connect to your router with the address of 192.168.1.1. This is done using MAC addresses rather than IP addresses. The result will be that your box will refuse to connect to the other router at all, much less request a DHCP lease from it. That will take dhcpcd out of the loop altogether.

Now the only question is how to tell it to do that... (I have done this on other distros in the past, using the network manager GUI, which is how I know it can be done.)

wrc1944 · 2010-02-05 22:44:00

OK- I rebooted with this line in /etc/conf.d/dhcpcd:

DHCPCD_ARGS="-q --nohook resolv.conf"

and /etc/resolv.conf with the "gateway" nameserver 192.168.1.1, and no ISP nameserver addresses.

This time, /etc/resolv.conf was NOT overwritten, and the connection was up, like normal! Finally!

route now reports:

[root@myhost wrc]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     202    0        0 eth0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
default         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
[root@myhost wrc]#

Apparently solved, but I'll wait for a few more reboots just to be sure before marking this thread.

Thanks much to all for sticking with me on this- I'd still like to know what suddenly caused Arch networking to behave like this.

Just for clarification, my system is set up like this:
Main router is linksys (192.168.1.1), wired to my main desktop computer (no wireless adapter installed), AND broadcasting a wireless signal to the secondary bridge T-Link wireless router (at 192.168.1.2), which runs my secondary desktop computer via wireless only, which is on the other side of the house in a position blocked from a direct linksys router signal.

sdolim · 2010-02-05 23:06:59

Seems odd that you have two default gateways in there (one with a 0 metric). Not sure where that's coming from.

wrc1944 · 2010-02-05 23:26:51

Could it have something to do with how I set the routers in bridge mode. I forget if I had to set both, or only one with the other's address. I do recall on the router config page in a browser, I did have to change the T-Link's address from 192.168.1.1 to 192.168.1.2, as by default they were both the same.

Then also, on the wireless computer's config (using wicd on one distro, and the Mandriva wireless config tools on Mandriva and Pclos) I had to specify 192.168.1.2 as the access point (T-Link router), because it could also see the very much weaker linksys AP 192.168.1.1 signal, and appeared to be confused as to which one to connect to.

However, I can't see how all of this could affect the wired system's resolv.conf file, because it doesn't even have a wireless adapter card with which to see the other router. Maybe because the linksys is playing a dual role, as in wireless and wired? Obviously I'm not understanding something here. All I can say for sure is that DHCPCD_ARGS="-q --nohook resolv.conf" seems to have worked.

I have used MAC addresses too, as well as iwconfig commands to set up wireless on Gentoo, so that was my next idea, if it still didn't work.

Last edited by wrc1944 (2010-02-05 23:55:12)

sdolim · 2010-02-06 00:28:19

I just now noticed that you added your /etc/dhcpcd.conf to an earlier post. These are the options that you would probably want to turn off/comment out in that file (not that it matters now since you found another way to do it via --nohook):

option domain_name_servers, domain_search

These tell dhcpcd to ask the server for values to write into resolv.conf.

Also, however it is being done, you are clearly getting lease offers from both routers:

dhcpcd: eth0: offered 192.168.1.100 from 192.168.1.2 `'
dhcpcd: eth0: ignoring offer of 192.168.1.100 from 192.168.1.1

First come, first serve -- that's why the 2nd offer was ignored. But which server responds first may change randomly.

wrc1944 · 2010-02-06 05:55:27

sdolim,
Thanks for all the info- I see what you mean about those other options. I'll be the first to admit I know relatively little about networking.

What I don't yet understand is how the Arch install on the wired box even can be offered a lease from the T-link at 192.168.1.2, since it doesn't have a wireless adapter card and so is not able to receive wireless signals. It just makes no sense. But it must be doing it somehow, as the two routers are (and of course need to) communicate with each other.

None of the other distros on this box have ever been offered that 2nd T-Link lease, so it must be something in the Arch method of configuring this stuff, and/or the router's setup. I thought (could be wrong on this) that when you run an ethernet cable out of a linksys router port, it was basically just routing the cable modem signal directly to the computer, and had nothing to do with any wireless signals the router was processing and then broadcasting. I doubt it, as I've done several of these setups before and can't recall seeing one, but maybe on the linksys router settings page there's an option to select which bridged router offers a lease first?

Anyway, as an example, here is the output of route for my main Gentoo installation, that I'm on right now:

gentoo wrc # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     2      0        0 eth1 
loopback        localhost       255.0.0.0       UG    0      0        0 lo   
default         192.168.1.1     0.0.0.0         UG    2      0        0 eth1

Right off I see that Arch doesn't show or have the loopback localhost line.

sdolim · 2010-02-06 06:46:00

I'm no network wizard either

I can only guess that the wired router is passing along DHCP lease offers from the wireless router, in addition to its own. There should be a config option to disable that on the router's web page.

Some of the metric numbers in your routing tables looked a little odd to me, so I just did a "man route" and checked the definition of "metric" in the route table:
The 'distance' to the target (usually counted in hops).

This means that a metric of 202 (see your post #17) is kind of far, almost as if your two routers are playing ping-pong with your IP packets for awhile before passing them on to your ISP. Do you notice any network sluggishness on your Arch machine? (Edit: the high metric could be related to having two default gateway entries instead.)

BTW, no the linksys is not just passing through cable modem signals to the wired ports. It's acting as a gateway (possibly firewall too).

Last edited by sdolim (2010-02-06 06:58:28)

wrc1944 · 2010-02-06 07:46:15

sdolim wrote:

I can only guess that the wired router is passing along DHCP lease offers from the wireless router, in addition to its own. There should be a config option to disable that on the router's web page.

Sounds right to me- but why would only Arch and not all the other distros be picking this up? Plus, previous to Feb2, Arch wasn't doing this either. so it must be an Arch update somewhere, but I can't figure out where. IMHO, must be a distro config difference of some kind involved, in addition to a linksys router setting.

All this new info is food for thought, but I need to get some sleep. I'll look more into this tomorrow.

Thanks much for all the great feedback!

sdolim · 2010-02-06 11:36:40

Never mind on that 202 metric. I found this in man dhcpcd.conf:

metric metric
         Metrics are used to prefer an interface over another one, lowest wins.
         dhcpcd will supply a default metric of 200 + if_nametoindex(3).  An extra
         100 will be added for wireless interfaces.

wrc1944 · 2010-02-07 16:42:51

sdolim,
Interesting on the metrics info- thanks. I guess since

DHCPCD_ARGS="-q --nohook resolv.conf"

in /etc/.conf.d/dhcpcd, and putting 192.186.1.1 in resolv.conf works (connection has survived 3 reboots), I can go with that for now, and mark this problem solved. Again, many thanks for all your help!

Oh yeah- I just installed Linux Mint in sda13 on this box (replacing a very very old Ubuntu Studio installation), and the NetworkManager in Mint couldn't seem to configure a simple wired connection. I removed NM, went with Wicd, but even it had problems. I then discovered that Mint's resolv.conf was also being overwritten with the T-Link wireless 192.168.1.2 address. I edited back 192.168.1.1, and it connected. On reboot, it connected, but removed 192.168.1.1 and wrote in my ISP's three nameserver addresses. This bears watching, and hopefully it won't start occurring on my other distros.

I'm thinking that maybe this old Linksys "b" only router isn't dealing with newer distros as well as it once did, even though I've updated its firmware to the latest version (which even so is from 2005 or maybe 2007 at the latest IIRC). I really don't expect any more updates for that, so I might need to get a more up-to-date modern router for the main hub.

Arch Linux

#1 2010-02-04 10:31:41

Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#2 2010-02-04 20:20:29

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#3 2010-02-04 20:30:27

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#4 2010-02-04 20:52:20

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#5 2010-02-05 02:44:21

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#6 2010-02-05 18:30:26

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#7 2010-02-05 20:18:39

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#8 2010-02-05 20:23:52

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#9 2010-02-05 20:28:41

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#10 2010-02-05 20:39:12

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#11 2010-02-05 20:55:58

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#12 2010-02-05 21:05:42

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#13 2010-02-05 21:33:19

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#14 2010-02-05 21:49:45

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#15 2010-02-05 22:14:28

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#16 2010-02-05 22:32:27

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#17 2010-02-05 22:44:00

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#18 2010-02-05 23:06:59

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#19 2010-02-05 23:26:51

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#20 2010-02-06 00:28:19

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#21 2010-02-06 05:55:27

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#22 2010-02-06 06:46:00

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#23 2010-02-06 07:46:15

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#24 2010-02-06 11:36:40

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

#25 2010-02-07 16:42:51

Re: Yet another dhcpcd network connection failure[SEEMS FIXED NOW]

Board footer