You are not logged in.
I'm trying to get on the wired network of my place of work (volunteering, so this isn't a total catastrophe), but no matter what I do, I can't seem to get eth0 to see that there's anything to connect to. The setup is a crossover cable running to a switch, which in turn is running to the main switch which is connected to our router. All the Windows machines connected to this switch work fine; they're just plug and play, and get their IP addresses via DHCP. I would like to do the same thing on my laptop (wireless works fine, but it's not always reliable here…the connection occasionally hangs), but neither Wicd nor iputils can seem to detect that there's any kind of network on eth0.
The module for the device is loaded:
lappy486 ~ $ inxi -N
Network: Card-1: Intel Centrino Advanced-N 6200 driver: iwlwifi
Card-2: Marvell Yukon Optima 88E8059 [PCIe Gigabit Ethernet Controller with AVB] driver: sky2
lappy486 ~ $ lsmod | grep "sky2"
sky2 49411 0
The interface shows up in ip link:
lappy486 ~ $ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
link/ether 00:24:54:87:43:50 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000
link/ether 18:3d:a2:5c:b6:90 brd ff:ff:ff:ff:ff:ff
…but no matter what way I plug this cable in and mess around with the interface configuration (I've tried manually assigning an IP address, default route, DNS servers, etc.), it's as if there's nothing there; not even ifplugd does anything. I've even tried plugging directly into the main switch with the same results. Could this be a hardware issue? Something as simple as a dirty ethernet port? It seems pretty clean to me, and I've blown it out to make sure there wasn't any dust (though I suppose I could try a compressed air can if that's really the issue ).
Any help on this would be appreciated, even if this just turns out to be a PEBKAC.
Last edited by MrCode (2012-11-23 19:29:05)
Offline
Just an update:
It seems to show a carrier when I boot with the cable plugged in, but dhcpcd still can't lease an IP address from the router. It will also report the carrier to have been lost on occasion (it comes back, though). If I bring the interface down manually, it goes back to the way it was before.
Last edited by MrCode (2012-11-24 00:29:35)
Offline
Another update (apologies for all the bumps):
I can still connect to my desktop machine at home with the crossover cable I have, so it appears this is definitely a configuration problem, or perhaps the wrong kind of cable…? It would strike me as odd that the Windows machines on the network there work when connected via crossover cable, but my laptop doesn't.
Offline
I can still connect to my desktop machine at home with the crossover cable I have, so it appears this is definitely a configuration problem, or perhaps the wrong kind of cable…? It would strike me as odd that the Windows machines on the network there work when connected via crossover cable, but my laptop doesn't.
If the switch does not support Auto MDI-X, and your laptop also does not, then that would be the case if the Windows machines do support MDI-X. That is a feature of the network hardware; it's almost certain that you have totally different NIC hardware than the Windows machines.
Have you tried another cable? (preferably not a x-over cable)
Another switch port with a different cable?
Another network (ie, work or home) with the questionable cable?
Can you boot a LiveCD (Ubuntu, SystemRescueCD, Finnix etc) on your laptop and get it working?
Last edited by fukawi2 (2012-11-25 22:22:01)
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Use mii-tools to possible reset the interface.
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
If the switch does not support Auto MDI-X, and your laptop also does not, then that would be the case if the Windows machines do support MDI-X. That is a feature of the network hardware; it's almost certain that you have totally different NIC hardware than the Windows machines.
I totally didn't know that…now I know why the Windows machines work with it, at least: the switches and/or the NICs on the Windows machines probably do support automatic MDI-X detection.
My lappy's NIC has a Marvell chipset:
07:00.0 Ethernet controller: Marvell Technology Group Ltd. Yukon Optima 88E8059 [PCIe Gigabit Ethernet Controller with AVB] (rev 11)
I have no idea if it supports automatic MDI-X detection, though…I'll look into it.
EDIT: I looked at the spec sheet PDF for my NIC, and the only mention of MDI I could find was this:
[…]
- Integrated termination passives for PHY MDI interface
[…]
I rather doubt this is what I'm after, though.
Have you tried another cable? (preferably not a x-over cable)
[…]
Another switch port with a different cable?
I've tried connecting to the main switch with a standard straight-through cable, but that didn't work, either. The guy who normally maintains the network for the place mentioned that switch has a few dead ports, though, so maybe I was just plugging into a dead port.
I could try plugging into the proxy switch using the (very short; wouldn't be able to use this permanently if it worked) straight-through cable, though; I admittedly haven't tried that yet.
Another network (ie, work or home) with the questionable cable?
I wouldn't be able to take it home, as it's not my property; it was bought for the organization. Also, there's only one network there, and that's the one I'm trying to get on via Ethernet.
Can you boot a LiveCD (Ubuntu, SystemRescueCD, Finnix etc) on your laptop and get it working?
I suppose I could try that as well, but now that I know about the MDI thing, I'm starting to think this is definitely a physical communications issue, rather than software/configuration.
Last edited by MrCode (2012-11-26 00:10:30)
Offline
…just tried connecting to the proxy switch with a couple different straight-through cables, and got the exact same behavior as before: no carrier unless I reboot with the cable plugged in, and even then, no DHCP lease. So perhaps it's not an issue with the wiring? This is really stumping me, and it's getting frustrating…
Last edited by MrCode (2012-11-26 17:56:45)
Offline
Try the LiveCD suggestion; that will identify if it's a lower-level issue (hardware, firmware, BIOS etc) or a configuration issue with your Arch install.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Got an similar issue on a friends server with the (intel) e1000e module loaded. Check if ethtool <dev> finds the device, if not it seems to be in a low powerstate. Remove any custom udev-rules on pci-devices regarding powersettings.
Knowing others is wisdom, knowing yourself is enlightenment. ~Lao Tse
Offline
Try the LiveCD suggestion; that will identify if it's a lower-level issue (hardware, firmware, BIOS etc) or a configuration issue with your Arch install.
I'll try to remember to bring in some kind of LiveCD tomorrow; haven't had the chance to test anything today due to being busy, and I hadn't brought a disc in anyways…
Check if ethtool <dev> finds the device, if not it seems to be in a low powerstate.
eth0 definitely shows up, and what do you know, there's actually a status message for MDI-X:
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: Unknown!
Duplex: Unknown! (255)
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown <-----------------
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: no
This is just from running "ethtool eth0" without any cable plugged in, but I'll try it with my home crossover cable (connected to my desktop), and with the switch at work, and see what I get.
(Somehow I doubt this is the problem now, but I'll still look at it when I can.)
Last edited by MrCode (2012-11-28 03:00:23)
Offline
Sorry for the late reply…haven't had time (and/or just forgot ) to test anything until now, but here are my results so far:
Trying with an older Arch LiveCD (2011.08), "ip link" shows a carrier with eth0, and bringing up the interface manually and leasing an IP address wth dhcpcd works fine. I've tried copying the version of iputils on the LiveCD to my package cache and installing it, but that made absolutely zero difference. Would systemd have anything to do with this? The old LiveCD is initscripts-based, and I've updated my installed systemd to a (mostly) native systemd setup (I say "mostly" because I use systemd-sysvcompat which "fixes" a bug with the Xfce shutdown/logout dialog not working properly).
If so, I have no idea where to even begin troubleshooting. My knowledge of unit files and how they're used by systemd is quite limited; I've neither written nor even modified a systemd unit file before.
I suppose I could spend some time RTFMing…
Offline
Well at least you can stop running around plugging cables and switches like a 1950's switch board operator
Unfortunately this is where I run out of ideas too I'm sorry
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Trying with an older Arch LiveCD (2011.08), "ip link" shows a carrier with eth0, and bringing up the interface manually and leasing an IP address wth dhcpcd works fine. I've tried copying the version of iputils on the LiveCD to my package cache and installing it, but that made absolutely zero difference.
Perhaps it’s the ethernet drivers in the kernel? Maybe see if you can run the kernel version that the live CD uses.
Offline
Perhaps it’s the ethernet drivers in the kernel?
Strange…I just now tried rmmoding and re-modprobing the sky2 module, and it seems to be working; I'm on wire as I post this. O.o
…so it does appear to be some kind of weird driver problem. What, though, I have no idea.
Offline
Perhaps it’s the ethernet drivers in the kernel?
Strange…I just now tried rmmoding and re-modprobing the sky2 module, and it seems to be working; I'm on wire as I post this. O.o
…so it does appear to be some kind of weird driver problem. What, though, I have no idea.
I've been having the same problem for weeks, too. atl1e driver in my case, so probably not specific to a single one. Never had any issues before that, and wireless connections still work automatically.
Offline
MrCode wrote:Perhaps it’s the ethernet drivers in the kernel?
Strange…I just now tried rmmoding and re-modprobing the sky2 module, and it seems to be working; I'm on wire as I post this. O.o
…so it does appear to be some kind of weird driver problem. What, though, I have no idea.
I've been having the same problem for weeks, too. atl1e driver in my case, so probably not specific to a single one. Never had any issues before that, and wireless connections still work automatically.
This is a bug with last NetworkManager package I guess. I took one week for notice it even the log does not showing nothing (I reinstall system 3 times with differents DE with same results (Xfce, Gnome and KDE), I had to install WICD to use wired network. Strange
Last edited by JohnnyDeacon (2013-02-20 17:06:52)
Offline
Never used NetworkManager myself though, but WICD ever since I installed Arch.
The weird thing is, occasionally it does automatically work after boot just as it should.
lspci -v:
02:00.0 Ethernet controller: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)
Subsystem: Acer Incorporated [ALI] Device 0146
Flags: bus master, fast devsel, latency 0, IRQ 51
Memory at da300000 (64-bit, non-prefetchable) [size=256K]
I/O ports at 4000 [size=128]
Capabilities: [40] Power Management version 2
Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [58] Express Endpoint, MSI 00
Capabilities: [6c] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [180] Device Serial Number ff-a9-df-7d-00-a0-d1-ff
Kernel driver in use: ATL1E
dmesg | grep ATL1E:
[ 14.476425] ATL1E 0000:02:00.0: irq 51 for MSI/MSI-X
[ 14.476555] ATL1E 0000:02:00.0 eth0: NIC Link is Up <100 Mbps Full Duplex>
ip link show dev eth0:
3: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
link/ether 00:a0:d1:a9:df:7d brd ff:ff:ff:ff:ff:ff
ip link set eth0 up won't do anything about that.
I've also tried and let the module be loaded early on boot via tee /etc/modules-load.d/atl1e.conf <<< "atl1e", but that didn't change anything, either. Until I do a rmmod atl1e ; modprobe atl1e ; dhcpcd eth0 it's always:
dhcpcd eth0
dhcpcd[3717]: version 5.6.7 starting
dhcpcd[3717]: eth0: waiting for carrier
dhcpcd[3717]: timed out
Nothing with dhclient, either.
edit:Also cleaned up /etc/rc.conf and /etc/sysctl.conf, no change.
/var/log/messages is funny. On virtually every boot there's a different combination of all sorts of messages regarding eth0 — sometimes multiple dhcpcd instances run after another after a previous one acquired and then immediately lost the carrier, sometimes dhcpcd just times out once, etc. etc.
Last edited by misc (2013-02-20 20:00:44)
Offline
After a recent upgrade I now have this same problem. eth0 has "NO-CARRIER".
Edit.
Looks a bit like this: https://bugs.launchpad.net/ubuntu/+sour … ug/1098298
Last edited by erikw (2013-03-21 08:02:44)
Offline
After a recent upgrade I now have this same problem. eth0 has "NO-CARRIER".
Edit.
Looks a bit like this: https://bugs.launchpad.net/ubuntu/+sour … ug/1098298
I'm having the same issue.
Last edited by jryan (2013-03-21 13:25:48)
Offline
This solves my problem: https://bbs.archlinux.org/viewtopic.php … 13#p994513
This may be caused by PCI power management.
I had the problem of "no carrier" when suspending with the Ethernet connection, and then resume.
This is a regression since I have no problem with this about two weeks ago before two recent "system -Syu"
Offline
I was having the same issue. However, I noticed sytemd-udevd calling ethtool somewhere during boot. And after installing ethtool, wired networking was working again.
Edit: Apparently it did not work in the long term. The temporary solution given by erikw did work however.
Last edited by kokx (2013-03-25 18:37:34)
Offline
So the "echo on > /sys/bus/pci/devices/0000:00:XX.0/power/control" indeed works but to make it permanent I had to set in /etc/laptop-mode/conf.d/ethernet.conf
CONTROL_ETHERNET=1
from "auto". Tuns out that the ethdev worked fine while on battery but no AC. Wonder why it has become like this. Any ideas?
Edit.
Maybe not, can not replicate that fix. The echo to sys still works though.
Last edited by erikw (2013-03-25 06:14:41)
Offline
I have the same issue. ethtool eth0 doesn't show an available device, but the echo fix that erikw suggested seems to work. I had this issue for a few days, I remember it started somewhere last Thursday or Friday, but I was suspecting the network here at work to be the cause.
Offline
Same issue. Only adding `on` to /power/control can fix it.
Offline
I'm hearing a report from the Ubuntu launchpad that 3.9 may fix this https://bugs.launchpad.net/ubuntu/+sour … ug/1112652
Last edited by erikw (2013-03-26 05:35:10)
Offline