Re: New motherboard, no network
On Tue, Mar 14, 2017 at 02:24:29PM +0000, Tony van der Hoff wrote:
> After many years, my faithful ASUS motherboard died, so I've replaced it
> with a Gigabyte GA-F2A68HM-HD2. t booted up fine from my existing disk
> set into Jessie, but networking is inoperative. The board has an
> on-board network interface, plus an extra PCI network board. Neither
> seem to be working, although they are recognised by lspci -v:
>
> #######################################
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
> Subsystem: Gigabyte Technology Co., Ltd Motherboard
> Kernel driver in use: r8169
>
> 02:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI
> Gigabit Ethernet Controller (rev 10)
> Subsystem: Realtek Semiconductor Co., Ltd. RTL8169/8110 Family
> PCI Gigabit Ethernet NIC
> Kernel driver in use: r8169
> #######################################
>
> ifconfig only lists one board, which appears inactive:
>
> eth0 Link encap:Ethernet HWaddr 6c:fd:b9:00:6f:76
> inet addr:192.168.1.7 Bcast:192.168.1.255 Mask:255.255.255.0
> 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)
>
> # PCI device 0x10ec:0x8169 (r8169)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="6c:fd:b9:00:6f:76", ATTR{dev_id}=="0x0",
> ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
> # PCI device 0x10ec:0x8168 (r8169)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="bc:ae:c5:29:77:d8", ATTR{dev_id}=="0x0",
> ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
>
> ############################################
>
> So, how do I get the network active?
Step 1. Check the cabling.
Step 2. Check the link: mii-tool eth0 or ethtool eth0
You want to see something like this:
eth0: negotiated 1000baseT-HD flow-control, link ok
Step 3. Check your switch/hub/link partner to see if it also
recognizes the link
Step 4. Try eth1, as well.
Step 5. Check for firewalling (iptables -L) or routing (ip r)
anomalies.
-dsr-
Reply to: