Messages

I just recently upgraded my old APU1 running 20.7.<recent> to an APU4d4 because I keep getting drops of my WAN connection, it's like the DCHP times out and the router can't renew it properly.  I'm working along and suddenly things freeze and I can't work, or my kids come yelling that the Wifi is down.  Heh. 

So I goto Interfaces -> Overview -> igb3 and hit the 'renew' button.  Which usually works, but not always.  I might have to hit it multiple times. 

I log via syslog to my main home system which is on 24x7, so can anyone give good suggestions for what to look for in the logs to help diagnose this problem?  It's really frustrating when the kids are in school, or us parent's are on conference calls. 

Here's a snippet from my log:

opnsense[32236]: /usr/local/etc/rc.configure_interface: The command '/sbin/dhclient -c '/var/etc/dhclient_wan.conf' -p '/var/run/dhclient.igb3.pid' 'igb3'' returned exit code '15', the output was 'dhclient 41052 - - Starting delete_old_states() dhclient 44642 - - Comparing IPs: Old: 66.189.75.104 New: dhclient 47831 - - Removing states from old IP '66.189.75.104' (new IP '') 0 states cleared killed 0 src nodes from 1 sources and 0 destinations DHCPREQUEST on igb3 to 255.255.255.255 port 67 DHCPREQUEST on igb3 to 255.255.255.255 port 67 DHCPREQUEST on igb3 to 255.255.255.255 port 67 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 2 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 19'
Dec  1 11:50:30 gw dhclient[3571]: Starting delete_old_states()

It looks like it's a failure to properly renew the WAN DHCP client IP address for some reason.  Has anyone else seen this issue?  Any suggestions on what I can do to make it work better?

It would still be nice if it was a bit more robust on the WAN port.  My ISP (Charter) does something stupid and my APU1 (now APU4d4) running 20.7.<latest> keeps dropping the WAN connection randomly.  So the kids/wife yell and I scurry off to hit reload on the Interfaces page.  Total pain.  It *never* used to do this with 19.x or earlier releases, but I also suspect my ISP is under alot more load now that we're all home.

But.... how can I make it more robust?  Or how can I log more and better data to see what's actually happening?  That's the big question. 

I just went through this, though I went from an APU1c (three gigE ports) to the APU4d4 (with 4 ports and a bigger SSD).  Since this old APU1 was the home router with the kids and wife depending on it being up all the time, I felt it was cheaper to just buy what I needed so I could set it up from scratch with a clean install.

My old system has been in use for 5+ years and multiple OPNsense upgrades, and I felt it was better to make a clean break.  Also, SSDs and such have gotten better and cheaper, so I was able to get it all sent from CH for $175 US, which was a steal.  And great service too.

But, you should be able to just move the SSD over, assuming that the right drivers are compiled into the image, which they should be.  If you can take the downtime, just try it out when the family is asleep.  *grin*

Just to chime in here, I'm running 20.7.4 (just updated to it last night) on an APU2 and it's working ok.  In in the USA and have Charter/Spectrum for my WAN and it keeps dropping randomly at times.  I usually have to go into the web GUI and renew the GW lease.  I haven't been able to figure out what's going on here.

I've got the 4gb RAM APU2 with three GigE ports, no Wifi at all, it's just a router and that's it.  I'm using a 64Gb mSATA SSD as my boot device, but I've only got 32gb partitioned and even less in use.  I figure that's a great way to keep up longevity as the wear leveling should keep things going nicely.

I syslog to my main home machine, and I still don't see messages in the logs when the gateway goes down.

Any suggestions on how to debug this better?  Can I reset the WAN DHCP from the console so I can watch for errors?  It's driving me nuts since a reboot tends to fix up the problem right away.

This system has been ugpraded from older releases, so maybe I really need to do a fresh 20.7.4 install on a wiped system.  Should I try to save off the config and restore it?  Or should I just re-enter all my local firewall rules (just a couple for NAT'ing some devices on the inside) and local DNS entries?  It would be nice if there was a way to export/import a list of entries all at once. 

John

I too ran into the same problem, but my /var/etc/dnsmasq-hosts was set to mode 640.  Once I did a chmod 644 and then restarted the servers (DNS Forwarder under services) it started working again.

In my opinion, the solution is two parts:

1. do a chmod after you finish the update to make sure the file is the proper mode. 

2. Log an error message when you can't read the file.  This is so much harder to solve without useful log messages.


Also, a bunch of my logs have all grown really large for some reason:

root@gw:/var/log # ls -ltr
total 9364
drwx------  2 root   wheel     512 Jul 25 19:01 suricata
drwx------  2 www    www       512 Jul 25 19:04 lighttpd
drwxr-x---  2 squid  squid     512 Jul 25 19:11 squid
drwxr-xr-x  2 root   wheel     512 Sep 10 23:06 installer
-rw-------  1 root   wheel  511488 Sep 10 23:08 ipsec.log
-rw-------  1 root   wheel  511488 Sep 10 23:08 openvpn.log
-rw-------  1 root   wheel  511488 Sep 10 23:08 squid.syslog.log
-rw-------  1 root   wheel  511488 Sep 10 23:08 portalauth.log
-rw-------  1 root   wheel  511488 Sep 10 23:08 ppps.log
-rw-------  1 root   wheel  511488 Sep 10 23:08 relayd.log
-rw-------  1 root   wheel  511488 Sep 10 23:08 wireless.log
-rw-------  1 root   wheel  511488 Sep 10 23:08 vpn.log
-rw-------  1 root   wheel  511488 Sep 10 23:08 lighttpd.log
drwxr-xr-x  2 root   wheel     512 Sep 10 23:10 ntp
-rw-------  1 root   wheel  511488 Sep 10 23:26 gateways.log
-rw-------  1 root   wheel  511488 Sep 10 23:26 resolver.log
-rw-------  1 root   wheel  511488 Sep 10 23:26 routing.log
-rw-------  1 root   wheel  511488 Sep 10 23:27 ntpd.log
-rw-------  1 root   wheel  511488 Sep 10 23:27 filter.log
-rw-------  1 root   wheel  511488 Sep 10 23:27 system.log
-rw-------  1 root   wheel     130 Sep 11 03:01 mount.today
-rw-------  1 root   wheel  511488 Oct 22 14:44 suricata.syslog.log
-rw-------  1 root   wheel    3061 Nov 29 03:01 setuid.yesterday
-rw-------  1 root   wheel   10660 Nov 29 03:01 dmesg.yesterday
-rw-------  1 root   wheel   41398 Dec  1 03:01 dmesg.today
-rw-------  1 root   wheel    3061 Dec  4 03:01 setuid.today
-rw-------  1 root   wheel     284 Dec  4 03:01 pf.yesterday
-rw-------  1 root   wheel     407 Dec  5 03:01 pf.today
-rw-------  1 root   wheel  511488 Dec  5 08:25 dhcpd.log
-rw-------  1 root   wheel   10245 Dec  5 08:29 userlog
-rw-r--r--  1 root   wheel       0 Dec  5 08:29 lastlog
-rw-r--r--  1 root   wheel     197 Dec  5 19:02 utx.lastlogin
-rw-r--r--  1 root   wheel     290 Dec  5 19:02 utx.log


And they have a bunch of binary data at the end.  It's as if they all got corrupted somehow.