RT-AX86U Log Level Question(s)

CZKid

New Around Here
I recently purchased an RT-AX86U following the advice of the esteemed contributors to this forum, and have been impressed with the speed and coverage of this fine router. I keep an eye on the log file, and noticed that it had loads of dnsmasq and similar network related entries, so using SSH I logged in and did the following to reduce the amount of routine logging:
  1. nvram set log_level=5
  2. nvram commit
  3. reboot
This same command sequence worked fine on my RT-AC1900P, which was replaced by the AX86U, and reduced the amount of junk that went into the log file. Once the AX86U rebooted and got through the boot sequence and settled down, I now get the log seen below. The firmware upgrade checks are normal, but the random key value generation is something new.

Two questions:
What are the random key values used for (this is a pretty frequent asynchronous event), and is there any reason to be aware of this at this log level (5)?

Will this sort of activity eventually fill the log space until something bad happens (mem overflow?), or is there an aging process that truncates the older log entries?

Setup info: Standard firmware, 3.0.0.4.386.46061, <10 wireless devices, 2 ethernet ports used, most traffic through attached 8-port gigabit switch, no mesh network. Plain vanilla config.

Thanks for any insight into this,

Peter

May 28 15:49:17 kernel: cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
May 28 10:49:39 crond[1581]: time disparity of 2137604 minutes detected
May 28 10:50:11 rc_service: cfg_server 2068:notify_rc restart_time;restart_upnp;restart_usb_idle;
May 28 10:50:11 dropbear[2097]: Early exit: Terminated by signal
May 28 10:50:11 syslogd exiting
May 28 10:50:11 hour monitor: daemon is starting
May 28 10:50:11 hour monitor: daemon terminates
May 28 10:50:15 kernel: wl0: random key value: 76D6C12EA2C90B5E794D019E0686BC30402AFD0C5B8D0DF8DC7A872AA2DD4E49
May 28 10:50:16 kernel: wl0: random key value: 3C04E5E2134438385E810268768E5F66190A075F6E610351491207D7870D6006
May 28 10:50:32 ahs: [read_json]Update ahs JSON file.
May 28 10:50:32 get_ext_phy_id: 0/1/0/0
May 28 10:50:34 ahs: [self_healing]pattern_index-[9].
May 28 10:50:34 ahs: [self_healing]re_pattern-[get_ext_phy_id:].
May 28 10:50:34 ahs: [self_healing]take action-[store_state].
May 28 10:50:49 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7419)]periodic_check AM 5:8
May 28 10:50:49 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7458)]do webs_update
May 28 10:50:52 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7476)]retrieve firmware information
May 28 10:50:52 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7479)]user in use
May 28 10:51:22 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7458)]do webs_update
May 28 10:51:22 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7476)]retrieve firmware information
May 28 10:51:22 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7479)]user in use
May 28 10:51:52 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7458)]do webs_update
May 28 10:51:52 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7476)]retrieve firmware information
May 28 10:51:52 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7479)]user in use
May 28 10:52:42 kernel: FPM Pool 1: invalid token 0x206c8000 freed
May 28 10:53:11 kernel: FPM Pool 1: invalid token 0x206d0000 freed
May 28 10:54:54 kernel: wl0: random key value: FCEBFAC1206E9348291B00EBBA92A6F4BAECD3C150590FA1F5FE3EF7FC4DB369
May 28 10:55:36 kernel: wl0: random key value: DB8C65393B3D964F01E700E586553B8E5015C0D5577409B9BCBD68619E311952
May 28 10:56:34 kernel: wl0: random key value: ACC5EF276273244502B30238CCE3181F41F94FDEE0F00570676D79275015C9CA
May 28 10:59:19 kernel: wl0: random key value: 4A813EF11150EBD2450701EC54097C0CBBE664AD80640F816FF68D11B3AF452C
May 28 11:00:58 disk_monitor: Got SIGALRM...
May 28 11:02:59 kernel: wl0: random key value: 9B98DD39C8BE6C4D4CC8006C353C6670D7268CF6A95A0BB19AFC59EB7C9D95A6
May 28 11:25:48 kernel: wl0: random key value: 897E1334D92E39BF3AE90014E2F4BC7FFF8CBFA68E050B90BBD9A6F8A96863B5
May 28 11:25:57 kernel: wl0: random key value: 7797E3133842ADEF194D01433B30EEC7575F3EF225EE059B1D2AA6FF3A114F0B
May 28 11:26:07 kernel: wl0: random key value: 6072EEC04C3E64854350018D833E8D0839EF3E404EB2041E4EFAF95B0F26BABD
May 28 11:26:31 kernel: wl0: random key value: F66112DD4B52C5121CC000AC56FC60CB1EAE123F117A00D2B07F26C9515BE562
May 28 11:26:40 kernel: wl0: random key value: 0BB15714D640B6932A4C002449DD6549915084C9EFE30091CC242FF3E021BD7E
May 28 11:32:12 kernel: wl0: random key value: 78E9D2D56D75D2D659C3033053592EF109370C95719F06E173E269500EC7C807
May 28 11:32:37 kernel: wl0: random key value: D5477D003482D9B919530202FE176D637F5487ADA57C0A5733149C5FF53F6F10
May 28 11:33:11 kernel: wl0: random key value: 0084B9DD6E5EE22524D000684E011BED11BADA14FE7F079CAE6E3E6C4ACD236A
May 28 11:33:58 kernel: wl0: random key value: B200F1FF5342105A166A00C795C723BD27451AD2805D077727690DBE9A4EFC04
May 28 11:34:41 kernel: wl0: random key value: 445CFEECB9D4164C066B011BDCFCC240CDB38D5C620E04A610D445045AEAACC1
May 28 11:35:58 kernel: wl0: random key value: 0546A1665C0B475C5ADE021654035CC65A10E3A8B4E502682C431E324E65D3E5
May 28 11:39:07 kernel: wl0: random key value: 6E9E020B84331A06408503B46FE3EDB700ED430FF76E09BD13EB7A4C5A93F28D
May 28 12:00:53 kernel: wl0: random key value: 4E08BFBF109599612B8C03BEE9DDDBDE02500459A5DE0087C59A57B4016A7B02
May 28 12:01:10 kernel: wl0: random key value: 1665DF70F12842FC1F1E022A260ACA8D8A4FF3EF9A73024F1738DEEB1B723A60
May 28 13:15:42 kernel: wl0: random key value: 34745FE5377CB4EE0E9103AB8992D9353055935BA87103A857C5B5D4951AA43A
May 28 13:15:53 kernel: wl0: random key value: 2EA54C6993A4F7175C7302B6F5D4AA9D105825CC48E00CAB9C0790472CE1C6BF
May 28 13:52:27 kernel: wl0: random key value: 6145FCD31EC7BD4E53B7005E61090C2FEE8B31738F3903958D24E4A0AEBDB11A
May 28 14:00:18 kernel: wl0: random key value: 2E3BE93B8FA52F1A004B03D64DFCC6866CABF354172B0024FB2177FBB88801A7
 

ColinTaylor

Part of the Furniture
What are the random key values used for (this is a pretty frequent asynchronous event), and is there any reason to be aware of this at this log level (5)?
The router generates a new random key every time a WiFi client is deauthorised (e.g. it disconnects). Asus have chosen to hard-code the log level, perhaps to help them debug custom's WiFi problems.

Will this sort of activity eventually fill the log space until something bad happens (mem overflow?), or is there an aging process that truncates the older log entries?
The answer is the same as when you asked it before: https://www.snbforums.com/threads/rt-ac86u-log-and-memory-consumption.69902/post-658840
 

CZKid

New Around Here
Colin,
Thanks for your reply. I guess I'm stuck with the random key log entries. I guess I'm lucky as there are relatively few devices connected, and that will somewhat limit the number of disconnects.

Regarding the RT-AC86U, I returned it to the chap that sold it to me after a few days as it suffered from the 2.4GHz radio dropping out (thermal issue?) that seems characteristic of that model. The AX86U seems to be more robust (and more speedy with 4 cores), and having more memory free space the additional log entries probably won't be an issue. Thanks for the tip about my previous post; I'd forgotten I'd inquired about this issue earlier and returned to using my old reliable AC-1900P. I'll try out the "free" command and see how memory usage progresses.

Cheers,

Peter
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top