Understanding AsusWRT syslog

[Big Ry]

I have an AC68U running Merlin at my house. I have expressvpn service and have a couple vpn severs configured in Merlin for a handful of clients. Most don't run through the VPN though. I also have the router setup as an OpenVPN client for remote access.

Generally speaking everything runs fine, but i have some intermittent issues with internet access on a couple clients. And once in a while the routers WiFi just goes down for no apparent reason, the SSIDs aren't visible to any client. This is all typically fixed with a reboot, but I'm trying to figure out why it's happening. The loss of WiFi seems to be increasing in frequency, and with both myself and my wife working from home, this is a problem.

I've gone into the syslog numerous times, but the problem is that I really don't know what the hell I'm looking at. By no means am I any kind of expert on networking, far from it actually. There are always tons of entries related to expressvpn, and i don't know if this is normal or not. Last night our WiFi went out around 1am and stayed out until i rebooted this morning at 10am. The syslog says something about a usb device initializing or something. I have nothing connected to the usb ports on the router. I only have 2 clients hardwired directly and 7 clients hardwired via a Netgear unmanaged PoE switch (2 are dahua ipcams).

So I'm wondering if anyone knows of a good resource for explaining these various entries in the syslog. Something a bit more direct to the point that just googling the entries, because it's kind of hard to determine if the search results are what i want when i know nothing about this stuff. Isn't there some kind of resource that tells you what each log reference means?

P.s.- what happened to SNB on Tapatalk? It doesn't show up there anymore, and trying to open my previous threads in Tapatalk produces an error. Did SNB dump Tapatalk?

 

[eibgrad]

Beware, OpenVPN is, by its very nature, "chatty". A lot of what you see is normal. For example, if a connection drops and needs to be reestablished, and you're using the verb 4 or more (which I recommend), you get all the details, from the shutdown to the rebuild. Also, even during normal operations, the session key has to be renegotiated from time to time (default is 3600 secs, or 1 hour), and that shows up as well.

So the fact there's a lot of OpenVPN records in the syslog usually doesn't mean much. Not unless you see *obvious* problems, like the inability to connect, can't resolve the domain name of the remote/server, failed authentication, etc.

So unless you can point to something specific wrt OpenVPN, sounds more like a local wifi problem.

 

[Big Ry]

Beware, OpenVPN is, by its very nature, "chatty". A lot of what you see is normal. For example, if a connection drops and needs to be reestablished, and you're using the verb 4 or more (which I recommend), you get all the details, from the shutdown to the rebuild. Also, even during normal operations, the session key has to be renegotiated from time to time (default is 3600 secs, or 1 hour), and that shows up as well.

So the fact there's a lot of OpenVPN records in the syslog usually doesn't mean much. Not unless you see *obvious* problems, like the inability to connect, can't resolve the domain name of the remote/server, failed authentication, etc.

So unless you can point to something specific wrt OpenVPN, sounds more like a local wifi problem.

Will I didn't want to post my entire log cause it's enormous (404kb text file). But looking at it now, there are a ton of log entries like this one below. The log begins around 2am, and the first half of the log is repeats of the entries below.

Aug 14 03:22:08 dnsmasq-dhcp[231]: DHCPDISCOVER(br0) f4:f5:d8:ff:78:45
Aug 14 03:22:08 dnsmasq-dhcp[231]: DHCPOFFER(br0) 192.168.1.85 f4:f5:d8:ff:78:45
Aug 14 03:22:08 dnsmasq-dhcp[231]: DHCPREQUEST(br0) 192.168.1.85 f4:f5:d8:ff:78:45
Aug 14 03:22:08 dnsmasq-dhcp[231]: DHCPACK(br0) 192.168.1.85 f4:f5:d8:ff:78:45 Chromecast-Ultra

These were nearly every log entry until the scheduled router reboot at 4am. Scanning through them, it appears there's about 15-20 of these entries every 61-62 seconds. I recently added an HDFury Vertex2 to my desktop for video capture, and it has an Ethernet connection that's connected to my PoE switch. I'm wondering if the device is causing these issues.

There were a bunch of entries after the reboot, but some that stood out to me as possible problems were:

Aug 14 04:00:07 avahi-daemon[17924]: Found user 'nobody' (UID 65534) and group 'nobody' (GID 65534).

And

Aug 14 04:00:07 avahi-daemon[17924]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Aug 14 04:00:07 avahi-daemon[17924]: No service file found in /tmp/avahi/services.
Aug 14 04:00:07 avahi-daemon[17924]: Loading new alias name RT-AC68U.
Aug 14 04:00:07 avahi-daemon[17924]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.

And

Aug 14 04:00:07 syslog: Error unlocking 0: 9 Bad file descriptor
Aug 14 04:00:08 dnsmasq[231]: exiting on receipt of SIGTERM

And

Aug 14 04:00:16 WAN_Connection: ISP's DHCP did not function properly.
Aug 14 04:00:16 nat: apply redirect rules
Aug 14 04:00:16 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Aug 14 04:00:17 kernel: br0: port 3(eth2) entering forwarding state
Aug 14 04:00:17 kernel: br0: port 2(eth1) entering forwarding state
Aug 14 04:00:17 kernel: br0: port 1(vlan1) entering forwarding state
Aug 14 04:00:17 kernel: et0: et_mvlan_netdev_event: event 9 for vlan1 mvlan_en 0
Aug 14 04:00:17 kernel: device eth0 left promiscuous mode
Aug 14 04:00:17 kernel: et0: et_mvlan_netdev_event: event 2 for vlan1 mvlan_en 0
Aug 14 04:00:17 kernel: device vlan1 left promiscuous mode
Aug 14 04:00:17 kernel: br0: port 1(vlan1) entering disabled state
Aug 14 04:00:17 kernel: device eth1 left promiscuous mode
Aug 14 04:00:17 kernel: br0: port 2(eth1) entering disabled state
Aug 14 04:00:17 kernel: device eth2 left promiscuous mode
Aug 14 04:00:17 kernel: br0: port 3(eth2) entering disabled state
Aug 14 04:00:17 kernel: et0: et_mvlan_netdev_event: event 6 for vlan1 mvlan_en 0
Aug 14 04:00:17 kernel: et0: et_mvlan_netdev_event: event 17 for vlan1 mvlan_en 0
Aug 14 04:00:17 kernel: et0: et_mvlan_netdev_event: event 6 for vlan2 mvlan_en 0
Aug 14 04:00:17 kernel: et0: et_mvlan_netdev_event: event 17 for vlan2 mvlan_en 0

 

[Big Ry]

Then it began logging a bunch of USB entries. And as you can see below, the logs then switch to May 5th out of nowhere. I've seen this in the log many times in the past, no matter if it's Merlin or stock AsusWRT, and no matter what version I'm running... Always May 5th. What does this mean? Why may 5th?

Aug 14 04:00:20 kernel: usbcore: deregistering interface driver cdc_mbim
Aug 14 04:00:20 kernel: usbcore: deregistering interface driver cdc_ncm
Aug 14 04:00:20 kernel: usbcore: deregistering interface driver qmi_wwan
Aug 14 04:00:20 kernel: usbcore: deregistering interface driver cdc_wdm
Aug 14 04:00:20 kernel: usbcore: deregistering interface driver rndis_host
Aug 14 04:00:20 kernel: usbcore: deregistering interface driver cdc_ether
Aug 14 04:00:20 kernel: usbcore: deregistering interface driver asix
Aug 14 04:00:20 kernel: usbcore: deregistering interface driver cdc_acm
Aug 14 04:00:20 kernel: usbcore: deregistering interface driver usblp
Aug 14 04:00:20 syslogd exiting
May  5 01:05:03 syslogd started: BusyBox v1.25.1
May  5 01:05:03 kernel: klogd started: BusyBox v1.25.1 (2020-06-28 13:57:06 EDT)
May  5 01:05:03 kernel: Linux version 2.6.36.4brcmarm (merlin@ubuntu-dev) (gcc version 4.5.3 (Buildroot 2012.02) ) #1 SMP PREEMPT Sun Jun 28 14:07:12 EDT 2020
May  5 01:05:03 kernel: CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7f
May  5 01:05:03 kernel: CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
May  5 01:05:03 kernel: Machine: Northstar Prototype
May  5 01:05:03 kernel: Ignoring unrecognised tag 0x00000000
May  5 01:05:03 kernel: bootconsole [earlycon0] enabled
May  5 01:05:03 kernel: Memory policy: ECC disabled, Data cache writealloc
May  5 01:05:03 kernel: MPCORE found at 19020000
May  5 01:05:03 kernel: On node 0 totalpages: 65536
May  5 01:05:03 kernel:   DMA zone: 256 pages used for memmap
May  5 01:05:03 kernel:   DMA zone: 0 pages reserved
May  5 01:05:03 kernel:   DMA zone: 32512 pages, LIFO batch:7
May  5 01:05:03 kernel:   Normal zone: 4864 pages used for memmap
May  5 01:05:03 kernel:   Normal zone: 27904 pages, LIFO batch:7
May  5 01:05:03 kernel: PERCPU: Embedded 7 pages/cpu @c8215000 s5472 r8192 d15008 u65536
May  5 01:05:03 kernel: pcpu-alloc: s5472 r8192 d15008 u65536 alloc=16*4096
May  5 01:05:03 kernel: pcpu-alloc: [0] 0 [0] 1
May  5 01:05:03 kernel: Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 60416
May  5 01:05:03 kernel: Kernel command line: root=/dev/mtdblock2 console=ttyS0,115200 init=/sbin/preinit earlyprintk debug
May  5 01:05:03 kernel: PID hash table entries: 1024 (order: 0, 4096 bytes)
May  5 01:05:03 kernel: Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)

This is the point at which it stopped logging with the may 5th date:

May  5 01:05:25 kernel: tdts: tcp_conn_max = 8000
May  5 01:05:25 kernel: tdts: tcp_conn_timeout = 300 sec
May  5 01:05:25 WAN_Connection: WAN was restored.
Aug 14 04:02:03 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth AC:E2:D3:20:D5:C6, status: Successful (0)
Aug 14 04:02:03 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc

Then there's this, which I'm not sure what this means:

Aug 14 04:02:14 ovpn-server1[1018]: OpenVPN 2.4.9 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 28 2020
Aug 14 04:02:14 ovpn-server1[1018]: library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.08
Aug 14 04:02:14 ovpn-server1[1036]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 14 04:02:14 ovpn-server1[1036]: PLUGIN_INIT: POST /usr/lib/openvpn-plugin-auth-pam.so '[/usr/lib/openvpn-plugin-auth-pam.so] [openvpn]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY
Aug 14 04:02:14 ovpn-server1[1036]: Diffie-Hellman initialized with 2048 bit key
Aug 14 04:02:14 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth CC:F7:35:FE:21:3D, status: Successful (0)
Aug 14 04:02:14 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc CC:F7:35:FE:21:3D, status: Successful (0)
Aug 14 04:02:14 ovpn-server1[1036]: TUN/TAP device tun21 opened
Aug 14 04:02:14 ovpn-server1[1036]: TUN/TAP TX queue length set to 1000
Aug 14 04:02:14 ovpn-server1[1036]: /sbin/ifconfig tun21 10.8.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Aug 14 04:02:14 kernel: ADDRCONF(NETDEV_CHANGE): tun21: link becomes ready
Aug 14 04:02:14 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 1C:4D:66:1C:42:07, status: Successful (0)
Aug 14 04:02:14 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc 1C:4D:66:1C:42:07, status: Successful (0)

And a conflict between openvpn and the dns?

Aug 14 04:02:17 ovpn-client1[1091]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:48: block-outside-dns (2.4.9)
Aug 14 04:02:17 ovpn-client1[1091]: Use --help for more information.
Aug 14 04:02:17 syslog: VPN_LOG_ERROR: 488: Starting OpenVPN failed...

And here the entries start to space out by several minutes:

Aug 14 04:03:07 dnsmasq-dhcp[231]: DHCPREQUEST(br0) 192.168.1.115 34:8a:7b:94:bf:3c
Aug 14 04:03:07 dnsmasq-dhcp[231]: DHCPACK(br0) 192.168.1.115 34:8a:7b:94:bf:3c android-128ab454342b6e2
Aug 14 04:03:07 dnsmasq-dhcp[231]: DHCPREQUEST(br0) 192.168.1.187 bc:76:5e:28:a4:f1
Aug 14 04:03:07 dnsmasq-dhcp[231]: DHCPACK(br0) 192.168.1.187 bc:76:5e:28:a4:f1 Galaxy-Tab-A-2016
Aug 14 04:03:44 syslog: WLCEVENTD wlceventd_proc_event(466): eth2: Deauth_ind 00:16:6F:F2:3B:B8, status: 0, reason: Unspecified reason (1)
Aug 14 04:09:25 syslog: WLCEVENTD wlceventd_proc_event(500): eth2: Auth 2C:4C:C6:D4:8A:88, status: Successful (0)
Aug 14 04:09:25 syslog: WLCEVENTD wlceventd_proc_event(529): eth2: Assoc 2C:4C:C6:D4:8A:88, status: Successful (0)
Aug 14 04:09:29 dnsmasq-dhcp[231]: DHCPDISCOVER(br0) 2c:4c:c6:d4:8a:88
Aug 14 04:09:29 dnsmasq-dhcp[231]: DHCPOFFER(br0) 192.168.1.101 2c:4c:c6:d4:8a:88
Aug 14 04:09:29 dnsmasq-dhcp[231]: DHCPREQUEST(br0) 192.168.1.101 2c:4c:c6:d4:8a:88
Aug 14 04:09:29 dnsmasq-dhcp[231]: DHCPACK(br0) 192.168.1.101 2c:4c:c6:d4:8a:88 Galaxy-S10
Aug 14 04:30:39 syslog: WLCEVENTD

And there's a bunch more crap like this all throughout the log. I don't know what any of it means. If this is all considered normal, then i guess something else happened. I do scheduled reboots to avoid these issues, but it seems the issue actually began with a scheduled reboot. I just want to make sure there's nobody remotely accessing my router and make sure i don't have some kind of configuration error causing conflicts. My desktops battery backup lost ethernet connectivity at 4:15am (per the APC email) and connection wasn't reestablished until i rebooted the router and modem this morning.

 

[eibgrad]

Only thing that caught my attention (the rest was pretty normal) was the following.

Aug 14 04:02:17 ovpn-client1[1091]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:48: block-outside-dns (2.4.9)
Aug 14 04:02:17 ovpn-client1[1091]: Use --help for more information.
Aug 14 04:02:17 syslog: VPN_LOG_ERROR: 488: Starting OpenVPN failed...

That seems like a configuration error on your OpenVPN client. I don't know if you added that directive (block-outside-dns) to the custom config field, or the OpenVPN client itself did.

 

[Big Ry]

Only thing that caught my attention (the rest was pretty normal) was the following.

Aug 14 04:02:17 ovpn-client1[1091]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:48: block-outside-dns (2.4.9)
Aug 14 04:02:17 ovpn-client1[1091]: Use --help for more information.
Aug 14 04:02:17 syslog: VPN_LOG_ERROR: 488: Starting OpenVPN failed...

That seems like a configuration error on your OpenVPN client. I don't know if you added that directive (block-outside-dns) to the custom config field, or the OpenVPN client itself did.

Hmm I'm not sure. I think i did need to add something to the config a while back... Can't remember why. It may have been that. Why does this matter? I have the rest of the clients set to use cloudfare dns.

 

[eibgrad]

Hmm I'm not sure. I think i did need to add something to the config a while back... Can't remember why. It may have been that. Why does this matter? I have the rest of the clients set to use cloudfare dns.

From the OpenVPN documentation ( https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage ):

-block-outside-dns Block DNS servers on other network adapters to prevent DNS leaks. This option prevents any application from accessing TCP or UDP port 53 except one inside the tunnel. It uses Windows Filtering Platform (WFP) and works on Windows Vista or later.
This option is considered unknown on non-Windows platforms and unsupported on Windows XP, resulting in fatal error. You may want to use --setenv opt or --ignore-unknown-option (not suitable for Windows XP) to ignore said error. Note that pushing unknown options from server does not trigger fatal errors.

The router is NOT a Windows platform (obviously).

 

[Big Ry]

From the OpenVPN documentation ( https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage ):

-block-outside-dns Block DNS servers on other network adapters to prevent DNS leaks. This option prevents any application from accessing TCP or UDP port 53 except one inside the tunnel. It uses Windows Filtering Platform (WFP) and works on Windows Vista or later.
This option is considered unknown on non-Windows platforms and unsupported on Windows XP, resulting in fatal error. You may want to use --setenv opt or --ignore-unknown-option (not suitable for Windows XP) to ignore said error. Note that pushing unknown options from server does not trigger fatal errors.

The router is NOT a Windows platform (obviously).

So what does this mean exactly? Is that line in the config creating problems? What do the two commands you listed do? Do they change anything about the actual functionality of the VPN or DNS, or are they merely for manipulating log output?

 

[eibgrad]

Again, I *assume* you placed that directive into the custom config field of the OpenVPN client when you configured it on the router.

That particular directive is *only* for configuring an OpenVPN client when the client is running on the Windows platform. The router is NOT running on Windows, but Linux. Therefore OpenVPN is complaining that it can't honor that directive and produces a fatal error. You have to remove that directive before it will start successfully.

The purpose of that directive is as it says, to prevent DNS leaks. The router uses other techniques to make sure that doesn't happen. One is the recommendation that you specify "Exclusive" for the Accept DNS configuration option on the OpenVPN client. This tells it to ignore all other DNS servers except those pushed from the OpenVPN server itself, and those servers will be accessed only over the VPN.

 

[Big Ry]

Again, I *assume* you placed that directive into the custom config field of the OpenVPN client when you configured it on the router.

That particular directive is *only* for configuring an OpenVPN client when the client is running on the Windows platform. The router is NOT running on Windows, but Linux. Therefore OpenVPN is complaining that it can't honor that directive and produces a fatal error. You have to remove that directive before it will start successfully.

The purpose of that directive is as it says, to prevent DNS leaks. The router uses other techniques to make sure that doesn't happen. One is the recommendation that you specify "Exclusive" for the Accept DNS configuration option on the OpenVPN client. This tells it to ignore all other DNS servers except those pushed from the OpenVPN server itself, and those servers will be accessed only over the VPN.

So i have 2 VPN servers configured in the router: 1 a UK server that I use for NFL game pass international, the 2nd a NJ server that's my daily driver. The UK server was the only one with the block dns command configured, but that server was turned off in Merlin. The NJ server is active but doesn't have that command. Both have accept dns set to exclusive, but i definitely still get dns leaks from time to time on the NJ server so clearly that doesn't work very well. I went ahead and erased the block dns command, especially seeing as how we might not even have an NFL season this year lol. But what about those other commands you mentioned? Are those still needed?

 

[eibgrad]

Well now you've introduced new information, and that has made things confusing to *me*.

Until now I was under the assumption this was a simple case of your home router configured w/ an OpenVPN client and most likely connecting to a commercial OpenVPN provider (PIA, PureVPN, ExpressVPN, etc.). If that was the case, you'd simply remove the directive from that client. Because that directive is ***only*** relevant to the OpenVPN client, NOT OpenVPN server! It's the client that cares about the potential for DNS leaks, and thus the client that decides how it wants to handle it via its local DNS configuration. The only time you'd see this on the OpenVPN server config is if it was "pushed" as a directive to the OpenVPN client. But it would never be used by the OpenVPN server for its own purposes.

So telling me you have this directive configured on your OpenVPN servers makes no sense.

Let's make sure I have the *full* picture.

I can't tell if the OpenVPN client and OpenVPN servers are on the same router, or different routers. The latter would make more sense, but that's NOT how you are describing it. It *sounds* like they are both (client and server) on the same router. Please clarify this point.

 

[Big Ry]

Well now you've introduced new information, and that has made things confusing to *me*.

Until now I was under the assumption this was a simple case of your home router configured w/ an OpenVPN client and most likely connecting to a commercial OpenVPN provider (PIA, PureVPN, ExpressVPN, etc.). If that was the case, you'd simply remove the directive from that client. Because that directive is ***only*** relevant to the OpenVPN client, NOT OpenVPN server! It's the client that cares about the potential for DNS leaks, and thus the client that decides how it wants to handle it via its local DNS configuration. The only time you'd see this on the OpenVPN server config is if it was "pushed" as a directive to the OpenVPN client. But it would never be used by the OpenVPN server for its own purposes.

So telling me you have this directive configured on your OpenVPN servers makes no sense.

Let's make sure I have the *full* picture.

I can't tell if the OpenVPN client and OpenVPN servers are on the same router, or different routers. The latter would make more sense, but that's NOT how you are describing it. It *sounds* like they are both (client and server) on the same router. Please clarify this point.

Sorry, i may be butchering the terminology here. First, everything is on one router. Under VPN>VPN Client, I have the expressVPN UK & NJ openvpn configured. So if I inadvertently called those "servers" when they're actually "clients", I apologize. The UK vpn client had that block dns command configured on it in the "custom configuration" box in Merlin. The NJ vpn client is the only active vpn client at the moment, and it has 6-7 client devices running through it (split tunneling). On top of these 2 VPN client, i have a VPN server configured in Merlin in the VPN>VPN Server tab, which I use to remotely access the router. This VPN server is also configured with openvpn, but there's nowhere in merlin to enter custom configurations, so i don't think i modified that one at all. So yes, i have both VPN clients an VPN servers configured on a single router.

 

[eibgrad]

Well based on the above, and as far as the only error message I saw in that syslog, if you removed that reference to block-outside-dns from the OpenVPN client, that problem should have gone away whenever you have that OpenVPN client activated.

Beyond that, your wifi problems are a completely different matter and I saw nothing else in the syslog to suggest what those problems might be. It all appeared to be rather normal, the kind of entries I'd expect to see.

 

[Big Ry]

Well based on the above, and as far as the only error message I saw in that syslog, if you removed that reference to block-outside-dns from the OpenVPN client, that problem should have gone away whenever you have that OpenVPN client activated.

Beyond that, your wifi problems are a completely different matter and I saw nothing else in the syslog to suggest what those problems might be. It all appeared to be rather normal, the kind of entries I'd expect to see.

I haven't used the vpn client that had that code in it. Are you saying it should only be causing issues if the vpn client is enabled?

It's hard to know which parts of the log to post without knowing what any of it means. Is there like common issues i might look out for in the log? Common WiFi errors, warnings, etc?

 

[eibgrad]

I haven't used the vpn client that had that code in it. Are you saying it should only be causing issues if the vpn client is enabled?

Yes. There's no way you'd get that particular message in the syslog unless the OpenVPN client was active and attempting to connect. It's trying to start and failing due to that directive being in the config.

Aug 14 04:02:17 ovpn-client1[1091]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:48: block-outside-dns (2.4.9)

Aug 14 04:02:17 ovpn-client1[1091]: Use --help for more information.
Aug 14 04:02:17 syslog: VPN_LOG_ERROR: 488: Starting OpenVPN failed...

That is absolutely, positively the OpenVPN client attempting to start, but failing.

It's hard to know which parts of the log to post without knowing what any of it means. Is there like common issues i might look out for in the log? Common WiFi errors, warnings, etc?

I don't know of anything specifically related to debugging using the syslog. A lot of guys around here just know from experience where to start looking, and see the syslog as just one of many resources. Despite its size, many times it's of little help.

I understand your frustration. This stuff can be extremely complex and hard to debug, even for experienced users. But there is no magical way around that problem. Just takes experience. And perhaps some skill at digging out relevant material from Google search (a blessing). Frankly, I'm amazed how many non-technical users (esp. those w/ little networking experience) get any of this stuff to work at all! I have *decades* of experience and work in the field, and even *I* get frustrated at times.

A lot of the syslog is just informational, confirming that certain processes started, that they initialized correctly, etc. In your syslog, the USB stuff is about the drivers being installed and configured correctly. It says nothing about whether you are or are not using the USB ports. The dhcp entries are just the dhcp server receiving dhcp requests from clients and confirming their assignments. The WLCEVENTD stuff is just clients getting associated w/ the wifi based on their MAC address (all successfully). All very normal. Most experienced users have trained themselves to not even notice that stuff *until* a problem arises.

FWIW, wifi is notoriously difficult to debug because you're dealing w/ radios, which means all kinds of weird problems can occur, from interference to failing wireless chipsets. Plus, the possibility of wireless driver errors or bugs. And so many wifi problems are due to *local* environmental conditions. I've seen the exact same wireless router work beautifully in one location, and turn to total crap in another! Or work fine, then degrade over time. That's why I try to never depend on wifi if I can help it. NOTHING beats a wired connection for reliability and peace of mind, even if that means powerline or MoCA. Wireless should always be your *last* resort.

Of course, there are the usual wifi recommendations, like trying a different channel/freq. Or using a "fixed" channel/freq rather than Auto. But I can't recall too many times when the syslog proved all that useful. Not unless it was a driver issue, and perhaps a driver couldn't load for some reason.

One of the things that many ppl don't realize when it comes to these wireless drivers is that the manufacturers provide them as a binary blog, NOT as source code to be compiled by the router developer. And so if anything *is* wrong w/ the drivers, it's very difficult to diagnose. And there's little more you can do than report it to the manufacturer and hope they address it in a future update. Just another reason that wifi is such a dicey proposition.

 

[Big Ry]

Most of my clients im having issues with are wired actually. In fact, in having issues AGAIN! I just created a new thread this time. Getting so frustrated with all this. My ac68u used to be so reliable. I don't even know if it's the router or the vpn service or what. But it is driving me nuts.