February 10, 201610 yr Short history - Up until 6 months ago I used the onboard NIC on my motherboard and started getting issues with the network interface not acquiring an IP address. It would take multiple reboots for the interface to finally get an IP. Thinking that it might be an issue with the onboard NIC, I purchased a DLINK PCI NIC and put it in the server. I disabled the onboard nic in the BIOS, of course. The new NIC didn't solve the issue. I still have issues with the interface acquiring an IP address whenever I reboot. Once an IP address is finally acquired, the server runs fine and there are no drops or network issues. I only have an issue on reboot. I've grabbed the section of the system log that relates to this and included it below. Signs are pointing to either a motherboard issue or an issue with how unraid is querying the interface. I'm leaning towards the former. Has anyone else experienced something similar? Feb 9 16:29:38 Tower dhcpcd[1270]: dhcpcd-6.8.1 starting Feb 9 16:29:38 Tower dhcpcd[1270]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' PREINIT Feb 9 16:29:38 Tower dhcpcd[1270]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' NOCARRIER Feb 9 16:29:38 Tower dhcpcd[1270]: eth0: waiting for carrier Feb 9 16:29:38 Tower kernel: r8169 0000:04:01.0 eth0: link down Feb 9 16:29:38 Tower kernel: r8169 0000:04:01.0 eth0: link down Feb 9 16:29:41 Tower dhcpcd[1270]: eth0: carrier acquired Feb 9 16:29:41 Tower kernel: r8169 0000:04:01.0 eth0: link up Feb 9 16:29:41 Tower dhcpcd[1270]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' CARRIER Feb 9 16:29:41 Tower dhcpcd[1270]: eth0: delaying IPv4 for 0.1 seconds Feb 9 16:29:41 Tower dhcpcd[1270]: eth0: using ClientID 01:c4:a8:1d:f8:fc:69 Feb 9 16:29:41 Tower dhcpcd[1270]: eth0: soliciting a DHCP lease Feb 9 16:29:41 Tower dhcpcd[1270]: eth0: sending DISCOVER (xid 0xa41e6cf), next in 4.7 seconds Feb 9 16:29:46 Tower dhcpcd[1270]: eth0: sending DISCOVER (xid 0xa41e6cf), next in 8.2 seconds Feb 9 16:29:54 Tower dhcpcd[1270]: eth0: sending DISCOVER (xid 0xa41e6cf), next in 16.5 seconds Feb 9 16:30:10 Tower dhcpcd[1270]: eth0: sending DISCOVER (xid 0xa41e6cf), next in 32.3 seconds Feb 9 16:30:38 Tower dhcpcd[1270]: received SIGTERM, stopping Feb 9 16:30:38 Tower dhcpcd[1270]: eth0: removing interface Feb 9 16:30:38 Tower dhcpcd[1270]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' STOP Feb 9 16:30:38 Tower dhcpcd[1270]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' STOPPED Feb 9 16:30:38 Tower dhcpcd[1270]: dhcpcd exited Feb 9 16:30:38 Tower logger: /etc/rc.d/rc.inet1: /sbin/dhcpcd -b -t 10 -h Tower -d -L eth0 Feb 9 16:30:38 Tower dhcpcd[1300]: dhcpcd-6.8.1 starting Feb 9 16:30:38 Tower dhcpcd[1300]: forking to background Feb 9 16:30:38 Tower dhcpcd[1303]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' PREINIT Feb 9 16:30:38 Tower dhcpcd[1300]: forked to background, child pid 1303 Feb 9 16:30:38 Tower dhcpcd[1303]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' CARRIER Feb 9 16:30:38 Tower dhcpcd[1303]: eth0: delaying IPv4 for 0.3 seconds
February 10, 201610 yr Community Expert Have you check the cat5 cable , the switch you are connecting to, the router and the modem? And rebooted all of those devices. I would certainly work on checking those out before I started with any thought of replacing a MB.
February 10, 201610 yr Author Yes, my router is a few months old, and I put a new cat5e cable from the unraid box to the router within the last month. I still get the same error with a new router and cable. It wouldn't hurt to try a third cable, though.
February 10, 201610 yr Community Expert Yes, my router is a few months old, and I put a new cat5e cable from the unraid box to the router within the last month. I still get the same error with a new router and cable. It wouldn't hurt to try a third cable, though. Make sure you got an active link between the NIC and the router/switch. A lot of the 'green' routers and switches will not detect/activate a port that it doesn't 'think' has an active device attached. I have had to replace a couple of switches for that issue.
February 11, 201610 yr Author I just replaced the existing cable with a brand new cat6 cable for a 2nd time and connected to a different port on my router. Still the same issue. I'm fairly certain it's not related to the router, cable, or NIC card. I get the same behavior with the on board and the PCI NIC. Oddly enough, I seem to get an IP on the 7th reboot fairly consistently. Once it has an IP, it hangs on to it and operates normally. The only common denominator that connects with the PCI and onboard NIC is the motherboard. I have another motherboard of the same type. I may have to swap it to eliminate that possibility.
February 11, 201610 yr Are you getting the same IP when it finally gets it? Is this router a basic wireless router or something from your Internet provider? Anything new added to network (wired or wireless) or router/device configuration changed around the time problem started?
February 11, 201610 yr When I had that particular problem I had another machine with the same ip as well I had another instance like that when I had two unRAID servers that some how had tower as their names too. lol
February 11, 201610 yr Community Expert Are you using the DHCP function of the router to get your IP address or have you assigned a static one? If you have using a static IP address, what is the address and how does that static address compare to the range that the DHCP process uses?
February 11, 201610 yr Author When I had that particular problem I had another machine with the same ip as well I had another instance like that when I had two unRAID servers that some how had tower as their names too. lol It's a static IP. The IP is reserved in DCHP, so there aren't any conflicts there. There are no other computers on the LAN with the same IP or name, either. The server always gets the same IP. edit: to clarify LAN is 192.168.xx. /24 & the Dynamic IP range between 10 and 40 and the static IPs are outside that range.
February 11, 201610 yr I'd try deleting the DHCP reservation from the router to see if that's the problem, or at least give the router a reboot (or preferably both, in that order). What kind of router is it? I had one running a version of OpenWRT that gave me tons of headaches with DHCP reservations.
February 11, 201610 yr Author It's an ASUS RT-AC68U with asuswrt-merlin firmware. There aren't any issues with my windows clients getting their reservation when they reboot, but it could be something specific to linux based operating systems. Removing the reservation from the router is a good idea. I'll give it a shot when I get home tonight.
Archived
This topic is now archived and is closed to further replies.