Ethernet not working on fresh install... (Dell Inspiron E1505)

sbellerby12 · 2010-12-19 22:01:07

Okay, so a while ago (back in like August or something, it was before Fall Term) I tried to do an installation of Arch, and then we got to be close enough to the school year that I didn't have time to finish it and I was so thoroughly unfamiliar with a CLI then that I couldn't actually follow instructions without instructions on following the instructions which was a bit of a problem.

I've since taken an introductory course in Unix/Linux during the Fall, making me somewhat more familiar with this problem. I mention all that in case I run into the same people who managed to be surprisingly (in a pleasant way) patient with me while I tried to resolve this. The good news is that this time I have a much better grasp of at least using the system at a command line level, so hopefully if anyone can figure out what's wrong I might at least have a drive with a working Arch installation before the term starts. I've gotten it to work before on other machines, but I'm stuck with something so basic I can't actually move forward without it:
Ethernet support is a no-go on my Inspiron E1505 Laptop (I don't know the exact chip, while re-reading the guides on the Wiki the only thing I've seen so far to find out is an hwdetect command but apparently I don't have that) and I can't seem to do anything to make it go.

ping www.google.com gives an unknown host problem, ping 192.168.1.1 replies that the network is unreachable (I'm certain I have the right one, typing that into my url bar in a browser on any other machine in the house brings me to a page where I can change my router settings)

From the last time I had this problem one of the theories that got tossed around had to do with the version of one of the pieces of software for handling networking having a bug in the 2010-05 image that didn't work so this time I went with the 2009-08 install, but it still has the same problem (this leads me to think this problem may have been around for a while) and the Wiki guide for the Inspiron 6400 (which is apparently almost all-around identical to the E1505, almost all the hardware there has at least one possible configuration that matches my system save an incorrect listing on the RAM for my Mobiliby Radeon X1300, but it still got the chip right and all) states that Ethernet should work out of the box. I still have several functioning distros that I can use for another term just fine so there's no need to be hasty about this, I'd just like to have a rolling-release distro with something resembling upstream KDE if I can get past this one (rather important) small issue in the installation process. Once I'm past that, I'm certain I can at least get it to a functional graphical state.

Strangely, every other distribution I've tried (I play around with lots of different ones on my thumb drives using live environments) has gotten not only the Ethernet but also the Wireless working without more than a quick click to tell it which network to connect to, so I know the modules and whatever else involved exist in some legally redistributable form that must be at least partially free, but I'm not exactly an expert in working on such a minimal setup and so I'm stuck on where to try to make this work, most of the guides at least seem to respond to different symptoms from my own and list solutions that don't remedy me of this.

Hopefully I can get this working this time around and then not have to go through another round of this over Spring Break...thinking of breaks by the way, I should probably mention that on somewhere between the 26th and 28th I'll be leaving for a couple days (I leave on one of those days, depending on which day it ends up being I expect to get back no later than the 1st) and although I will probably be able to respond sort of I'll be somewhere where the Internet availability will be...perhaps the best wording is I won't inherently be able to download anything massive for a few days around that time, and my hours to check back here will be limited, so I'm just throwing that out there before we get there in case this drags out nearly as long as it did last time.

Thanks in advance for any help on the problem. :-)

art84 · 2010-12-20 00:16:18

I'm not an expert, more likely a noob, but I'll try to give you some advices.

So, shortly, you have a Dell Inspiron E1505/6400 and your network doesn't work, but you know that other linux distros did well with it.
I think you must identify what kind of problem you have: hardware or software/configuration.

Try to run the following commands and write here what you get:

ifconfig -a

will show you all the network interfaces you have; normally, at least lo interface must be there (loopback)

dmesg | grep eth

will show you if there were loaded some modules related to network

lspci | grep net

will show you if your NIC is identified as a PCI device; something like "02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet Controller (rev 3)"

lsmod | grep mii

will show you what module was loaded for network and uses the "mii" module; something like "mii 3186 2 3c59x,r8169" - the last column enumerates the modules loaded for network interfaces, in my case 3c59x and r8169

Last edited by art84 (2010-12-20 00:27:03)

sbellerby12 · 2010-12-20 23:04:20

Well, here's each of them:

ifconfig -a:

eth0      Link encap:Ethernet  HWaddr 00:15:C5:AC:30:DA  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27 errors:0 dropped:0 overruns:0 frame:0
          TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12726 (12.4 Kb)  TX bytes:8539 (8.3 Kb)
          Interrupt:17 

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:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

wlan0     Link encap:Ethernet  HWaddr 00:18:DE:14:78:BA  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

wmaster0  Link encap:UNSPEC  HWaddr 00-18-DE-14-78-BA-00-00-00-00-00-00-00-00-00-00  
          [NO FLAGS]  MTU:0  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

The 'wmaster0' one is new, I don't remember ever seeing that one before. Either way though, Ethernet still acts like it's moving SOMETHING back and forth, but I still don't get to ping anything.

dmesg | grep eth:

Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:15:c5:ac:30:da
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.

When I saw this output it reminded me of last time, someone then (I think) thought it was establishing a connection, then dropping it at one point. Clearly if I were anything resembling knowledgeable in this area I'd have already known the command but from my point of view it looks like there's a lot of connecting and disconnecting for some reason.

lspci | grep net:

03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

This one sounds about right, and also happens to match the Arch Wiki here kinda nicely (which is nice, always good when the random guides are actually right about what I'm working with)

lsmod | grep mii:

mii                     4804  1 b44

Uh...what does this tell me?

Anyway, that doesn't get ME anything that I can figure out how to work with, but still the overall appearance from my end is that it might not actually be maintaining any connection once it's established? That would probably lead to the way it's behaving. There was a single time where trying to ping my router hardly a split second after logging in (as fast as I could type it) got a single packet returned before the ping froze and I had to ^C out of it (after which it returned to the typical unknown host/network unreachable errors) but anyway, hopefully this leads somewhere.

Also, thanks for shortening the description of the problem a little bit. Sorry, I do have a tendency to go on a little bit (it's how I talk, and I type how I talk, so it's how I type too...) but thanks for helping. :-)

~<>~
EDIT
~<>~
Looked at how you made those boxes, and realized that doing the same thing in my post might help just generally make it more readable.

~<>~
EDIT2
~<>~
*looks at post again* Ooohhhhh, so the module is b44? (did I get that right?)

Last edited by sbellerby12 (2010-12-20 23:08:10)

karol · 2010-12-20 23:27:00

sbellerby12 wrote:

*looks at post again* Ooohhhhh, so the module is b44? (did I get that right?)

your computer wrote:

b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
...

art84 · 2010-12-20 23:48:40

well ... from these logs it seems the hardware part is OK ("UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1")
the only strange behaviour is

b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
b44: eth0: powering down PHY
b44: eth0: Link is down.
b44: eth0: powering down PHY
b44: eth0: Link is up at 100 Mbps, full duplex.
...

but it could be due to a bad config

we will not touch wlan0 and wmaster0, ethernet is the goal

"mii 4804 1 b44" tells that module b44 is used by kernel to manage your "Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)" and I think it's the right module

now, when it's known that hardware is OK, let's check the config

1) do you have to use a DHCP or must you have a static IP?
2) open file /etc/rc.conf and have a loot at "NETWORKING" section
if you have to use DHCP, you must have

eth0="dhcp"

if you have to use a static IP (in this example 192.168.0.5):

eth0="eth0 192.168.0.5 netmask 255.255.255.0 broadcast"

put it in INTERFACES array:

INTERFACES=(eth0 lo)

and enable the gateway if it's not enabled yet:

gateway="default gw 192.168.0.1"
ROUTES=(gateway)

also have a loot at /etc/resolv.conf and put there some DNS servers' IPs (probably recieved from your ISP):

nameserver 123.123.123.123
nameserver 234.234.234.234
search localhost

sbellerby12 · 2010-12-21 00:40:24

Well, currently my machine is set to use DHCP, to the best of my knowledge all the machines in my house are automatically assigned an IP when they're turned on (either that, or they have all managed to cooperate in setting non-conflicting static ones in ways where even the Windows machine(s) are/have been happy, which seems unlikely) so that seemed like it was the correct one to use...that, and I'm slightly confused on how I would go about correctly establishing a static IP anyway (sorry, I don't have networking until next term) and haven't set one up before.

This should (if I understood the guide correctly) be a correct networking part of the rc.conf file:

# -----------------------------------------------------------------------
# NETWORKING
# -----------------------------------------------------------------------
#
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
#
HOSTNAME="spencer-laptop"

# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
#
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
#   - prefix an entry in INTERFACES with a ! to disable it
#   - no hyphens in your interface names - Bash doesn't like it
# 
# DHCP:     Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#

#Static IP example
#eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
eth0="dhcp"
INTERFACES=(eth0 wlan0)

# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
#   - prefix an entry in ROUTES with a ! to disable it
#
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
 
# Enable these network profiles at boot-up.  These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
#   - set to 'menu' to present a menu during boot-up (dialog package required)
#   - prefix an entry with a ! to disable it
#
# Network profiles are found in /etc/network.d
#
# This now requires the netcfg package
#
#NETWORKS=(main)

Yes, the hostname was also replaced correctly in /etc/hosts during the installation.

This is everything that resolv.conf says:

# Generated by dhcpcd
# /etc/resolv.conf.head can replace this line
# /etc/resolv.conf.tail can replace this line

I think that was supposed to be automatically generated by the automatic IP thing with dhcp anyway, at least again that's what I understood the guide to mean.

Is there some way to check that the module itself is functional? Or has something here already suggested that it's functional? (just thinking aloud)

Again, nice to have such quick responses. :-)

sbellerby12 · 2010-12-22 00:26:25

As I post this I'm at a relative's house for much of the day (I'll try to respond tonight if anyone gets around to posting here, but if I'm totally delayed then that's why) and the only option here is Ethernet and I'm using it with Ubuntu 9.10 at the moment on my laptop, so I'm figuring that there must be some kind of difference in how this is working that we might be able to spot. While I'm thinking about doing so, I figured I'd post some of the details from those commands while running Ubuntu instead of Arch just in case they'll help...

ifconfig -a:

eth0      Link encap:Ethernet  HWaddr 00:15:c5:ac:30:da  
          inet addr:192.168.15.2  Bcast:192.168.15.255  Mask:255.255.255.0
          inet6 addr: fe80::215:c5ff:feac:30da/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1400  Metric:1
          RX packets:208 errors:0 dropped:0 overruns:0 frame:0
          TX packets:229 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:115908 (115.9 KB)  TX bytes:30594 (30.5 KB)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:319 (319.0 B)  TX bytes:319 (319.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:18:de:14:78:ba  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wmaster0  Link encap:UNSPEC  HWaddr 00-18-DE-14-78-BA-00-00-00-00-00-00-00-00-00-00  
          UP RUNNING  MTU:0  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

dmesg | grep eth:

[    1.645971] eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:15:c5:ac:30:da
[  102.446788] ADDRCONF(NETDEV_UP): eth0: link is not ready
[  105.816218] b44: eth0: Link is up at 100 Mbps, full duplex.
[  105.816223] b44: eth0: Flow control is off for TX and off for RX.
[  105.816547] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  109.556055] b44: eth0: powering down PHY
[  109.816131] b44: eth0: Link is down.
[  112.816218] b44: eth0: Link is up at 100 Mbps, full duplex.
[  112.816223] b44: eth0: Flow control is off for TX and off for RX.
[  115.960046] eth0: no IPv6 routers present

lspci | grep net:

03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

lsmod | grep mii

mii                     5212  1 b44

Again, that's with Ubuntu 9.10 (I think the last time I updated it was over the weekend, so it should be whatever is the most recent they're willing to put in their repositories) and the Ethernet port is what I'm using to actually connect and post this so I'm absolutely certain that the hardware works and works with whatever information can be taken from those commands on this OS. Hopefully (or at least it would be nice if this worked) there might be a difference between the two systems that makes it clearer what's not working...

karol · 2010-12-22 07:30:45

Let's see if I'm getting this right: you posted this from Ubuntu, from your relative's house and you have a working Ethernet there, but not at your place?
If so, maybe your router is the culprit.

art84 · 2010-12-22 10:57:26

I've noticed the following:

from Arch:

eth0      Link encap:Ethernet  HWaddr 00:15:C5:AC:30:DA  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

from Ubuntu:

eth0      Link encap:Ethernet  HWaddr 00:15:c5:ac:30:da  
          inet addr:192.168.15.2  Bcast:192.168.15.255  Mask:255.255.255.0
          inet6 addr: fe80::215:c5ff:feac:30da/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1400  Metric:1
...

you have MTU = 1400 on Ubuntu and you also have obtained an IP address "inet addr:192.168.15.2 Bcast:192.168.15.255 Mask:255.255.255.0"
on Arch you have MTU = 1500 and NO address

the interface module is the same (b44), so more probable is that your router is not compatible by default with your NIC or you must change some settings to your router because it doesn't give you any IP

try also to 'play' with the MTU value, for example:

ifconfig eth0 mtu 1400

sbellerby12 · 2010-12-22 17:13:19

karol wrote:

Let's see if I'm getting this right: you posted this from Ubuntu, from your relative's house and you have a working Ethernet there, but not at your place?
If so, maybe your router is the culprit.

Actually, if it were a non-functional router then my Desktop (which I've been using to make posts while working directly with the laptop because the laptop (while running Arch), as is the point of this thread, can't connect to the Internet at the moment) wouldn't be able to connect, I know that the router is just fine and dandy, although you've got a good point that there might be some difference in what it's reporting with the router...I could repost those again using this router, I was just thinking that those posts might include differences in things like which versions of modules are being used and things like that just on the machine itself, which I'm reasonably confident is the source of the trouble, not the router.

Also, I'll start playing with that in a couple hours here, for the moment I'm stuck a few rooms away from the room with the Ethernet cable access but I'll try that out in a little while (and also just for the sake of having the same router and stuff, I'll repost those command outputs from Ubuntu using my own router, which also has working Ethernet just fine, if that proves necessary for making comparisons between the two in a helpful manner) and get back with (hopefully better) results.

~<>~
EDIT
~<>~
From the same exact connection that I've been using (with all this failure going on in effort to use it) with Arch I now use Ubuntu on the same laptop to make this post after running the same commands again. Here's what I've got from it:

ifconfig -a:

eth0      Link encap:Ethernet  HWaddr 00:15:c5:ac:30:da  
          inet addr:192.168.1.107  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::215:c5ff:feac:30da/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:102 errors:0 dropped:0 overruns:0 frame:0
          TX packets:132 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:55806 (55.8 KB)  TX bytes:15708 (15.7 KB)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:240 (240.0 B)  TX bytes:240 (240.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:18:de:14:78:ba  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:576 (576.0 B)

wmaster0  Link encap:UNSPEC  HWaddr 00-18-DE-14-78-BA-00-00-00-00-00-00-00-00-00-00  
          [NO FLAGS]  MTU:0  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

dmesg | grep eth:

[    1.617973] eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:15:c5:ac:30:da
[   22.215253] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   25.816197] b44: eth0: Link is up at 100 Mbps, full duplex.
[   25.816202] b44: eth0: Flow control is off for TX and off for RX.
[   25.821125] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   36.568049] eth0: no IPv6 routers present

lspci | grep net:

03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

lsmod | grep mii

mii                     5212  1 b44

So yeah, I'm quite sure that it's not the router causing the problem here.

If I'm reading it right, that MTU thing was different at a different location, but stayed the same here, so I'm wondering whether playing with that would still be a valid idea here. Also, I can't help but notice a value of roughly 400 in difference between the number from 'mii' on Arch and Ubuntu, Ubuntu's number the higher one. Is that like a difference in version or something, or is that irrelevant to making it work?

Last edited by sbellerby12 (2010-12-22 18:36:44)

art84 · 2010-12-22 19:45:44

so, post #3 contains the output when using the same PC, the same router and Arch Linux
post #10 contains the output when using the same PC, the same router and Ubuntu

MTU = 1500 is OK ... basically, this is the standard for Ethernet

in /etc/rc.conf you have:

INTERFACES=(eth0 wlan0)

probably it has no relevance, but try to remove wlan0, keep only (eth0)

the number from "mii" is not so important, it's the size (in bytes) of the "mii" module

anyway, maybe someone more experienced could help you, for me it's hard to say what's wrong .. probably some DHCP options/configuration, because you don't get any IP on Arch
try to read https://wiki.archlinux.org/index.php/Co … or_DHCP_IP and follow those instructions
or, if it's possible, try to build a static IP based network to be sure that it works at least that way and then switch back to DHCP-based and try to solve

sbellerby12 · 2010-12-22 23:50:22

I modified it to only contain eth0 and rebooted, but it still seems to think that there's nothing available to connect to even with only that.

Also, I tried looking at that link but I don't know any nameservers to give it myself, and I'm not exactly confident that I can set up a static IP following the steps it describes without probably managing to do something to my router and I really can't afford to do anything to cause my router to not work...(my networking experience is limited to things just automatically working and things only not working because of drivers, beyond that I really don't know all that much on getting it to work)

sbellerby12 · 2010-12-23 19:24:11

So, since having no Internet connectivity is something of a problem for running updates if it's the very first set of updates on the system mainly because the updates are kind of provided through the Internet, I can't help but wonder: is there some way to just get a list of all the packages that could possibly need downloading, take that to another machine, get those, put them on a thumb drive (I know those're working fine, it's how I got the feedback printed to file to post here) and update from that to see if one of those updates fixes it?

Is it worth trying to do that as a rather drawn out potential fix to the system without a connection here? If nothing else, it would give me a system as if I'd done a net install, right? At the very least, we would then know that we're working with the most recent versions of everything instead of an image built from August '09...

(I couldn't do a regular net install because the live image has the same problem as the core install image where it thinks Ethernet cables shouldn't work...)

Mr Green · 2010-12-23 20:13:37

Can you post your rc.conf

You could try one of the Arch based livecds to see if network works, Archbang for example

art84 · 2010-12-23 20:25:11

sbellerby12,
you also could have a look at https://wiki.archlinux.org/index.php/Co … ls_at_boot and follow all those steps

but on the other side, if your technical experience si somehow limited, maybe a better solution is to use a more friendly Arch-based distro ... or try to dig deeper and get your feet wet and dirty
Arch philosophy involves a more technical approach and not so much automatically working magic

sbellerby12 · 2010-12-23 23:30:36

My full rc.conf is as follows:

#
# /etc/rc.conf - Main Configuration for Arch Linux
#

# -----------------------------------------------------------------------
# LOCALIZATION
# -----------------------------------------------------------------------
#
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime"
# USEDIRECTISA: use direct I/O requests instead of /dev/rtc for hwclock
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
#
LOCALE="en_US.utf8"
HARDWARECLOCK="UTC"
USEDIRECTISA="no"
TIMEZONE="America/Los_Angeles"
KEYMAP="us"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"

# -----------------------------------------------------------------------
# HARDWARE
# -----------------------------------------------------------------------
#
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed
# MOD_BLACKLIST: Prevent udev from loading these modules
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.
#
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.
#
MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=() #deprecated
MODULES=()

# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"

# -----------------------------------------------------------------------
# NETWORKING
# -----------------------------------------------------------------------
#
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
#
HOSTNAME="spencer-laptop"

# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
#
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
#   - prefix an entry in INTERFACES with a ! to disable it
#   - no hyphens in your interface names - Bash doesn't like it
# 
# DHCP:     Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#

#Static IP example
#eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
eth0="dhcp"
INTERFACES=(eth0 wlan0)

# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
#   - prefix an entry in ROUTES with a ! to disable it
#
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
 
# Enable these network profiles at boot-up.  These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
#   - set to 'menu' to present a menu during boot-up (dialog package required)
#   - prefix an entry with a ! to disable it
#
# Network profiles are found in /etc/network.d
#
# This now requires the netcfg package
#
#NETWORKS=(main)

# -----------------------------------------------------------------------
# DAEMONS
# -----------------------------------------------------------------------
#
# Daemons to start at boot-up (in this order)
#   - prefix a daemon with a ! to disable it
#   - prefix a daemon with a @ to start it up in the background
#
DAEMONS=(@syslog-ng network netfs @crond)

As for trying Archbang to see if that works, I've currently got it downloading but it's fluctuating between like ~200KB/s and 1.0MB/s and the overall estimate says it's going to be a while, so I'll have to get back on how (or rather if) that works. If it does, I should be able to either just install that and work backwards to a basic Arch before customizing it and/or use some working component of that to make the standard Arch install work, right?

sbellerby12 · 2010-12-24 23:56:40

So this doesn't actually help with the Ethernet problem much, but Archbang didn't seem to feel like running off my thumb drive, it crashed partway through loading repeatedly and seemed to pull up an only half-functional terminal (which didn't recognize things like 'reboot' or 'init6' or really any command to shut down or restart the machine, which was odd) so I switched to trying Chakra, another Arch-based distro which has failed to work off a thumb drive entirely but when burned to a disk behaves strangely...

Chakra claims an error while booting:

[drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!

It seems odd, since that sounds like a graphics thing but I know I have a Mobility Radeon X1300 (says that all the way down to the BIOS with anything and everything I've ever checked with) though waiting long enough after that error reports some buffer thing (I was busy typing the first error while it went through those, glad I did because I thought it was just flat out not working at all until I left it there a few minutes while I typed this up) repeatedly it does actually start up sort of, although very slowly (I guess that's to be expected with an optical drive though) and then reaches a command interface after a short while...then starts up something graphical...

Anyway, now that it seems to actually partially work while I'm making this post I'm going to leave my post sitting here for a while, then return to it so I'm not typing things as they appear while they happen and I can actually give information regarding how an Arch-based distro behaves with the Ethernet (by the way, it detected both an eth0 and a wlan0 while booting) so we can see what's going on with that.

--------

Okay, so I can't seem to trick the command line into thinking I shouldn't need a password on the live disk to sudo the commands used, but the Ethernet worked right off the bat without doing a thing on Chakra.

The output of the commands is as follows (again) on Chakra:

ifconfig -a:

eth0      Link encap:Ethernet  HWaddr 00:15:C5:AC:30:DA  
          inet addr:192.168.1.107  Bcast:255.255.255.255  Mask:255.255.255.0
          inet6 addr: fe80::215:c5ff:feac:30da/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2356 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1794 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2999832 (2.8 Mb)  TX bytes:180592 (176.3 Kb)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:40 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2080 (2.0 Kb)  TX bytes:2080 (2.0 Kb)

wlan0     Link encap:Ethernet  HWaddr 00:18:DE:14:78:BA  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

dmesg | grep eth:

b44 ssb0:0: eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:15:c5:ac:30:da
b44 ssb0:0: eth0: Link is up at 100 Mbps, full duplex
b44 ssb0:0: eth0: Flow control is off for TX and off for RX
eth0: no IPv6 routers present

lspci | grep net:

03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

lsmod | grep mii:

mii                     3198  1 b44

And just to be absolutely sure that the Ethernet is working (none of the wireless points I can reach from here work without a password, and since live distros usually don't auto-guess those correctly I'm certain it's using Ethernet) I checked Google before posting that, and Yahoo after, and both loaded just fine including an interesting bunch of images today for Google and Yahoo's weird thing with the frozen free throw thingy, so I can't think of any other way rekonq would be able to load that besides through the Ethernet cable.

Also, so we have all the relevant information, I got the rc.conf and resolv.conf files off it too since those have been asked for previously from the fresh Arch installation:

rc.conf:

#
# /etc/rc.conf - Main Configuration for Arch Linux
#

# -----------------------------------------------------------------------
# LOCALIZATION
# -----------------------------------------------------------------------
#
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime"
# USEDIRECTISA: use direct I/O requests instead of /dev/rtc for hwclock
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
#
LOCALE="en_US.UTF-8"
HARDWARECLOCK="localtime"
USEDIRECTISA="no"
TIMEZONE="Canada/Pacific"
KEYMAP="us"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"

# -----------------------------------------------------------------------
# HARDWARE
# -----------------------------------------------------------------------
#
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed
# MOD_BLACKLIST: Prevent udev from loading these modules
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.
#
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.
#
MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=() #deprecated
MODULES=(vhba acpi_call)

# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"

# -----------------------------------------------------------------------
# NETWORKING
# -----------------------------------------------------------------------
#
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
#
HOSTNAME="chakra"

# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
#
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
#   - prefix an entry in INTERFACES with a ! to disable it
#   - no hyphens in your interface names - Bash doesn't like it
# 
# DHCP:     Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#

#Static IP example
#eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
eth0="dhcp"
INTERFACES=(!eth0 !eth1 !wlan0)

# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
#   - prefix an entry in ROUTES with a ! to disable it
#
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
 
# Enable these network profiles at boot-up.  These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
#   - set to 'menu' to present a menu during boot-up (dialog package required)
#   - prefix an entry with a ! to disable it
#
# Network profiles are found in /etc/network.d
#
# This now requires the netcfg package
#
#NETWORKS=(main)

# -----------------------------------------------------------------------
# DAEMONS
# -----------------------------------------------------------------------
#
# Daemons to start at boot-up (in this order)
#   - prefix a daemon with a ! to disable it
#   - prefix a daemon with a @ to start it up in the background
#
DAEMONS=(syslog-ng hal networkmanager hwdetect sshd xorg-detect xorg-config cdemud)

resolv.conf

# Generated by NetworkManager
domain Nesselroad
search Nesselroad
nameserver 75.75.75.75
nameserver 75.75.76.76

So from that I'd say clearly something can be done to Arch to make it work, it's simply a matter of figuring out what it is that needs to be done (If I understand correctly Chakra uses a modified version of KDE, I was hoping for the upstream version but if installing it and wiping the modded version could get me close to a base Arch + Ethernet working I could probably get everything else working from there...I'd use Chakra instead anyway but to the best of my understanding a lot of the modded stuff in it is supposedly still kind of Alpha-like and I need to know things are stable enough to not be labeled such on my laptop at the moment)

Hopefully that helps trace the source of the problem, it seems odd to me that nobody else has run into this issue but maybe it can be solved here for anyone else who does.

(<sarcasm>now watch the moment we solve it Arch will have a new installation version that fixed the problem anyway, you just know something like that has to happen...</sarcasm>)

sbellerby12 · 2010-12-25 05:22:54

By the way, just to narrow away some possibilities I made sure that the dhcpcd package is up to date (found it on the site, after much searching I found a way to update it from a thumb drive) and the problem persists. I attempted to do something similar to the kernel but found that trying to get ALL the dependencies/replacements/whatever proved a bit too complex for my time at this moment...

Thinking of that idea though, if I had another machine that I could get to work just fine at least to the point of connecting through Ethernet, I could just run an update on that and get ALL the packages in the /var/whatever area for pacman, then move those by thumb drive to my laptop to update ALL the things, right? (I actually happen to have a spare machine that I could attempt to revive for this, if anyone thinks it's a version-specific issue of one of the pieces of a standard Arch install...though it may well still simply be missing something in which case updates would be pointless, but an up-to-date system would at least remove the concern over it being a woefully outdated bug or anything)

~<>~
EDIT
~<>~
So I got that other machine which works just fine with connecting to the Internet (it's a really old desktop, I can't just use that in place of the laptop but it's currently not in use so I figured it would work for downloading the packages just fine) using Arch to do a full install of the same 2009/08 image and ran the updates, then I copied all the packages from what I think was /var/cache/pacman/pkg (or something like that, it DID have all the packages though) to a thumb drive. While trying to run an update with pacman -U /media/usb/* (I'd already mounted the thumb drive there) it mentions something about an error that replacing packages with -U isn't supported, and to try using -Rd and -U to replace them manually. Problem is, it's not very specific with how to do that correctly, but I do have all the updates as of December 25th at ~11:00 on the Pacific Coast (US) and I figure having not over-a-year-old Arch probably reduces the chances of this just failing over an old lack of support or something so unless there's a good reason not to just go ahead and do that for the moment it'd be nice if someone knew what to do about that.

For the sake of being clear about this update I'm trying to do, here's the output of "pacman -U *" while the working directory is /media/usb:

loading package data...
checking dependencies...
error: replacing packages with -U is not supported yet
error: you can replace packages manually using -Rd and -U
:: linux-api-headers: conflicts with kernel-headers
:: linux-firmware: conflicts with kernel26-firmware
:: pkg-config: conflicts with pkgconfig
:: procinfo-ng: conflicts with procinfo
:: xz: conflicts with xz-utils

By the way, a single line appeared outside of the output redirection, it read "error: failed to prepare transaction (conflicting dependencies)".

~<>~
EDIT2
~<>~
By the way, completely irrelevant to the whole lack of non-working Ethernet, but does anyone know why the updated vi behaves so strangely compared to the older one? So far as I can tell, it randomly decides that it no longer thinks I want to be in insert mode and then tries to run commands based on my typing as if insert mode was disabled, which with my typing speed gets it to try to do like 3 things by the time I actually notice that it's no longer in insert mode. If anyone knows what causes this behavior and/or how to fix it, that would be greatly appreciated.

Last edited by sbellerby12 (2010-12-25 19:43:26)

skeeter · 2010-12-26 03:36:56

Your Ubuntu at home comes up with an IP of 192.168.1.2 for eth0. Your rc.conf has your default gateway as 192.168.0.1. I would tend to think your router/gateway is set to 192.168.1.1 and if you change your rc.conf you might have some luck. Just my 2 cents.

sbellerby12 · 2010-12-26 05:05:10

I guess I'll give that a shot in a little bit here, though the default gateway is the same in both the installed standard Arch (which doesn't work) and the Chakra Live CD (which does work) so I can't help but not be too confident on that...

If that doesn't do it then I'll probably have to start using it regularly over Spring Break unless there's another good chunk of time coming up (I don't know how many days I'll have between returning and the term starting) that I just don't know about yet...

I'm using a separate hard drive to do this anyway so at least I could probably just keep that the way it is for the moment (unless they release either another 2010 image real quick here or an early 2011 one, in which case if the vi behaves and the monitor is detected as color-capable I might be able to tolerate it enough to install that) and maybe try to remember to check back...

(basically in short starting tomorrow I won't be trying to get this running, I'll stick with a release-cycle distro for now so I won't be checking back several times a day but rather once every few days or something because it'll be much less urgent to me, I still intend to get a nice rolling-release Arch on here the next time I have a spare week to be sure it'll keep running for school purposes)

F451 · 2016-10-27 20:54:00

I've run into the same problem during installation of my ethernet not working when it should be. Here's what worked for me-

run:

 systemctl start dhcpcd

then run:

 systemctl enable dhcpcd

jasonwryan · 2016-10-27 21:04:00

Please don't necrobump, especially with information that is readily available in the wiki: https://wiki.archlinux.org/index.php/Co … bumping.22

Closing

Arch Linux

#1 2010-12-19 22:01:07

Ethernet not working on fresh install... (Dell Inspiron E1505)

#2 2010-12-20 00:16:18

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#3 2010-12-20 23:04:20

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#4 2010-12-20 23:27:00

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#5 2010-12-20 23:48:40

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#6 2010-12-21 00:40:24

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#7 2010-12-22 00:26:25

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#8 2010-12-22 07:30:45

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#9 2010-12-22 10:57:26

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#10 2010-12-22 17:13:19

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#11 2010-12-22 19:45:44

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#12 2010-12-22 23:50:22

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#13 2010-12-23 19:24:11

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#14 2010-12-23 20:13:37

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#15 2010-12-23 20:25:11

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#16 2010-12-23 23:30:36

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#17 2010-12-24 23:56:40

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#18 2010-12-25 05:22:54

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#19 2010-12-26 03:36:56

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#20 2010-12-26 05:05:10

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#21 2016-10-27 20:54:00

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

#22 2016-10-27 21:04:00

Re: Ethernet not working on fresh install... (Dell Inspiron E1505)

Board footer