Solved Network connection goes off after turning PC off overnight

Hi, I'm fairly new to FreeBSD and for some reason I'm having a weird experience on how my setup is behaving on my network. I have 2 other operating systems on my rig (that's not even a year old), Archlinux, Windows 10 and FreeBSD, all installed on 3 separate SSD's. FreeBSD's volume is in GPT and using UFS filesystem. Right now I'm connected to the network, BUT everytime I would turn my PC off overnight and turn it on the next morning FreeBSD for some reason would not connect to the network automatically. I've tried everything I know to troubleshoot the problem and the only thing that worked for me is doing a hard reset by unplugging my PC and pressing and holding the power switch for 15 to 20 seconds. And then it would connect. Everyday it's like that.

This weird scenario doesn't happen on Archlinux and Windows 10. It works perfectly on those two. When it's not connected I'm getting "No DHCPOFFERS received" message on boot up and "Host not found" message when I do ping on the desktop.

Here's my /etc/rc.conf
Code:
hostname="cornibus"
ifconfig_alc0="DHCP"
ifconfig_alc0_ipv6="inet6 accept_rtadv"
sshd_enable="YES"
moused_enable="YES"
dbus_enable="YES"
hald_enable="YES"
slim_enable="YES"
linux_enable="YES"
oss_enable="YES"
kld_list="nvidia-modeset"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"

My /etc/resolv.conf
------------
Code:
nameserver 9.9.9.10
nameserver 9.9.9.9

My /boot/loader.conf
------------
Code:
linux_load="YES"
nvidia_load="YES"
fuse_load="YES"
snd_driver_load="YES"
snd_hda_load="YES"

My ifconfig(8) result ( ifconfig alc0)
------------
Code:
[B]alc0[/B]: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=c319a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MCAST,WOL_MAGIC,VLAN_HWTSO,LINKSTATE>
    ether 4c:c4:6a:23:c7:1d
    hwaddr 4c:c4:6a:23:c7:1d
    inet6 fe80::4ec4:6aff:fe23:c71d%alc0 prefixlen 64 scopeid 0x1 
    inet 192.168.10.100 netmask 0xffffff00 broadcast 192.168.10.255
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active

The ifconfig(8) result is the same when I'm not connected other than of course, the highlighted line with the local IP is missing.

Again I'm fairly new to FreeBSD and I'm loving it. I just need someone who can shed some light as to why it is behaving like that.

Thank you very much. Any response will be greatly appreciated.
 
So when you say "turn off" you are putting your machine in suspend or sleep mode, not shutdown / power off?
If so, some peripherals (usb and others) need special handling with regards to suspend / sleep mode. Some needs to be powered off before doing suspend or sleep, others need special handling after waking up from suspend or sleep. You need to investigate a bit more.
 
So when you say "turn off" you are putting your machine in suspend or sleep mode, not shutdown / power off?
No, it's neither suspend nor sleep mode. It's a complete shutdown / poweroff. I usually just do: shutdown -p now
Then the next morning, I'm getting a message at boot up telling me "No DHCPOFFERS received" again.
 
Some easy things to try ...

1. bounce the device with ifconfig
# ifconfig down
# ifconfig up

2. restart the netif service (I sometimes need this for wifi)
# service netif restart alc0

3. try commenting out the ipv6 related line in rc.conf

4. check your BIOS for a wake-on-lan feature and turn if off.
 
On a "broken" boot, check dmesg output and /var/log/messages for any errors around alc0 or networking or routing or DHCP. There should be something in there that points to what the issue is.
 
On a "broken" boot, check dmesg output and /var/log/messages for any errors around alc0 or networking or routing or DHCP. There should be something in there that points to what the issue is.

Thanks but my /var/log/messages looks fine to me. Or maybe I'm just overlooking things.

Code:
Feb 19 13:00:00 cornibus newsyslog[1251]: logfile turned over due to size>100K
Feb 19 13:24:25 cornibus kernel: alc0: link state changed to DOWN
Feb 19 13:24:28 cornibus kernel: alc0: link state changed to UP
Feb 19 13:24:35 cornibus kernel: alc0: link state changed to DOWN
Feb 19 13:24:37 cornibus kernel: alc0: link state changed to UP
Feb 19 13:24:40 cornibus kernel: alc0: link state changed to DOWN
Feb 19 13:24:42 cornibus kernel: alc0: link state changed to UP
Feb 19 13:24:46 cornibus dhclient: New IP Address (alc0): 192.168.10.100
Feb 19 13:24:46 cornibus dhclient: New Subnet Mask (alc0): 255.255.255.0
Feb 19 13:24:46 cornibus dhclient: New Broadcast Address (alc0): 192.168.10.255
Feb 19 13:24:46 cornibus dhclient: New Routers (alc0): 192.168.10.1
 
Some easy things to try ...

1. bounce the device with ifconfig
# ifconfig down
# ifconfig up

2. restart the netif service (I sometimes need this for wifi)
# service netif restart alc0
I've tried these two like a hundred times. Wake on LAN in the BIOS was actually one of the first things I checked and no luck.

3. try commenting out the ipv6 related line in rc.conf
By the way, this trick seem to have fixed the issue. I booted this morning and the network stays up. Will see after a couple more days if this issue will not persist then I will tag this as solved. And even after that, still it doesn't make sense to me. Anyway, thanks mate!
 
I think I just got lucky for a couple of days. Sadly it's the same problem when I booted up this morning and also when I rebooted twice for a couple of update, same problem. I'm now thinking of reinstalling maybe I just missed something.
 
@greencloud Are using a different os at night, and then in the morning using FreeBSD (after changing the boot device)?
Nope, only FreeBSD. I like it here because FreeBSD doesn't seem to put much strain on my hardware unlike my other OS. And I'm slowly getting the hang of it after more than a week of using it. I had lots of bumps along the way (all manageable by the way) but this one here, only this one, literally cause a pain in the rear because I had to crawl under my desk to do the only fix that worked (hard reset). The kind of fix that doesn't make sense to me at all.
 
This sounds similar to a spanning-tree behavior issue, but I don't think it is, because that issue I understood only affected Microsoft machines. The root cause issue there is default traditional spanning-tree behavior on a Cisco switch put spanning tree in blocking mode for 15 seconds on a port. For Microsoft machines that depended on DHCP the DHCP request would timeout before 15 seconds. So spanning-tree feature "portfast" got added, and as well, eventually a new generation of protocol called Rapid Spanning Tree addressed this issue too.

But I have never known this issue to affect *nix machines, but did want to throw that out there. I also noticed my latest home router seems to have a DHCP issue; it seems to miss the first DHCP request from some of my machines. My corporate laptop, and one of my smart TVs often need to try DHCP request a second time. These machines had no issue before with an older router. So any chance something funky going on with your router or maybe even your FreeBSD NIC? I can't help wonder that somehow your OS is simply not receiving the DHCP offer, but its not actually the OS that is the issue.
 
I can't help wonder that somehow your OS is simply not receiving the DHCP offer, but its not actually the OS that is the issue.
In a nutshell that's basically what's going on that's why I'm getting the "No DHCPOFFERS received" message. But as to why it does that, I have no idea. I also have other devices connected to my router. I have 3 other laptops running two Archlinux and one Windows 10, several Android phones and tablets. All those devices connects to the router without any problem at all. And that includes the two other OS's I have on this machine.
 
And you tried the easy stuff like switching around the cabling on your network switch?
I don't have to since everything else works but this... but I did it anyway a couple of times, yes. The last thing that I can think of is reinstalling FreeBSD but that would not be anytime soon.
 
Interesting issue. First: what phoenix said: check /var/log/messages. I know you said you did, but your paste doesn't show it. We're talking about looking at the logfile right after you booted and these issues showed up. And a logfile turning over during boot doesn't sound very likely to me. Also dmesg, in specific /var/run/dmesg.boot (or just the dmesg command after booting I suppose).

Another thing you can do which might shed more light on this: after you rebooted (and these issues show up) try using: # tcpdump -i alc0 to see what's actually being sent across your network.
 
That is the natural normal way to think, but I have seen that kind of thinking prove itself wrong a fair few times in my 25 years of heavy-duty internetworking.
I know. I agree. That is why I tried it anyway. Switching cables was actually one of the first things I tried doing.
 
Consider trying this too. Don't reboot the machine, but:

tail -f /var/log/messages
Unplug CAT cable; and wait as as long as need to ensure DHCP lease on router has expired.
Then plug CAT cable back in, and watch the log file.

How long is the DHCP lease on your router? And did you try changing to say a few days for example, just to see? Is your router a $50 plastic one, or some more industrial like Juniper or Cisco?
 
First of all I would like to thank you guys for trying to help me with this issue. I really appreciate it. Unfortunately, it's been more than a week now but still I have no luck.

I've tried PacketMan's suggestion:
tail -f /var/log/messages
Unplug CAT cable; and wait as as long as need to ensure DHCP lease on router has expired.
Then plug CAT cable back in, and watch the log file.
The previous lines has something to do with my audio so I will not put it here. The only line that was added to the output after I unplug the CAT cable was this:
Code:
Feb 25 15:53:49 anonymous kernel: alc0: link state changed to DOWN
After waiting for a couple of hours I plugged my CAT cable back in and these are the lines that were added to the output:
Code:
Feb 25 18:07:03 anonymous kernel: alc0: promiscuous mode enabled
Feb 25 18:09:14 anonymous kernel: alc0: link state changed to UP
Feb 25 18:10:00 anonymous newsyslog[3042]: logfile turned over due to size>100K
And that's it. I ran tcpdump -i alc0 as well and this is what came up:
Code:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on alc0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:32:44.121349 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:c4:6a:23:c7:1d (oui Unknown), length 300
18:33:02.093164 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:c4:6a:23:c7:1d (oui Unknown), length 300
18:33:17.060556 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 4c:c4:6a:23:c7:1d (oui Unknown), length 300
18:38:04.940372 IP 192.168.10.1.bootps > 192.168.10.100.bootpc: BOOTP/DHCP, Reply, length 548
18:38:04.940424 IP 192.168.10.1.bootps > 192.168.10.100.bootpc: BOOTP/DHCP, Reply, length 548
18:38:04.940429 IP 192.168.10.1.bootps > 192.168.10.100.bootpc: BOOTP/DHCP, Reply, length 548
18:38:04.940434 IP 192.168.10.1 > 224.0.0.1: igmp query v2
18:38:04.940443 IP 192.168.10.1.bootps > 192.168.10.100.bootpc: BOOTP/DHCP, Reply, length 548
18:38:04.940454 IP 192.168.10.1.37025 > 239.255.255.250.1900: UDP, length 264
I've check dmesg.boot as well and this is what I got:
Code:
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017
    root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
VT(vga): resolution 640x480
CPU: AMD FX(tm)-8350 Eight-Core Processor            (4000.18-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x3e98320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C>
  AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
  AMD Features2=0x1ebbfff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC>
  Structured Extended Features=0x8<BMI1>
  SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=65536
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8197492736 (7817 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: <ALASKA A M I>
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 8 core(s)
random: unblocking device.
ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20170303/tbfadt-796)
ioapic0 <Version 2.1> irqs 0-23 on motherboard
ioapic1 <Version 2.1> irqs 24-55 on motherboard
SMP: AP CPU #1 Launched!
SMP: AP CPU #6 Launched!
SMP: AP CPU #4 Launched!
SMP: AP CPU #5 Launched!
SMP: AP CPU #7 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #3 Launched!
Timecounter "TSC-low" frequency 2000088609 Hz quality 1000
random: entropy device external interface
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0xffffffff80f5b220, 0) error 19
nexus0
vtvga0: <VT VGA driver> on motherboard
cryptosoft0: <software crypto> on motherboard
pcib5: <ACPI PCI-PCI bridge> at device 21.0 on pci0
pci5: <ACPI PCI bus> on pcib5
alc0: <Killer E2200 Gigabit Ethernet> port 0xd000-0xd07f mem 0xfe100000-0xfe13ffff irq 16 at device 0.0 on pci5
alc0: 11776 Tx FIFO, 12032 Rx FIFO
alc0: Using 1 MSIX message(s).
miibus0: <MII bus> on alc0
atphy0: <Atheros F1 10/100/1000 PHY> PHY 0 on miibus0
atphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
alc0: Using defaults for TSO: 65518/35/2048
alc0: Ethernet address: 4c:c4:6a:23:c7:1d
nvme cam probe device init
alc0: link state changed to DOWN
alc0: link state changed to UP
urtwn0 on uhub6
urtwn0: <Realtek 802.11n NIC, class 0/0, rev 2.00/0.00, addr 2> on usbus5
urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
urtwn0: enabling 11n
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled
NOTE: Due to a very lengthy output I excluded some lines that I think is irrelevant with the issue such as outputs for my keyboard, mouse and external devices.

As for the DHCP lease time, I've already played with it as well from 2 hours, which is the default in my router, and up to 2 days. I'm using a TP-Link router, Model No. TL-WR740N, just a basic household router.
 
Hmmm, I might have missed understood the nature of this post. I thought you were saying that the machine is not getting an IP address via DHCP. But it looks indeed that it is being assigned and using 192.168.10.100 with a /24 (255.255.255.0) mask. What am I misunderstanding?
 
Hmmm, I might have missed understood the nature of this post. I thought you were saying that the machine is not getting an IP address via DHCP. But it looks indeed that it is being assigned and using 192.168.10.100 with a /24 (255.255.255.0) mask. What am I misunderstanding?
I'm afraid you just overlooked the timestamp on the output my friend. If you look closely on my last, after following what you have suggested, it took about 3 hours before I was able to get that IP address. But, even after I was able to get an IP, still I was not able to connect to the Internet.

When I saw that I had an IP I tried ping -c 5 8.8.8.8, nothing. I tried restarting the network via service netif restart, nothing. Dhclient is running already, so I stopped dhclient and ran it again, dhclient alc0, still nothing. So I just turned my PC off again, unplugged it, did the hard reset, booted up and voilà, it connected right away.

The main problem starts at boot up and that's where I get the "No DHCPOFFERS received" message.
 
Back
Top