YazFi Network Map Errors

[Jeffrey Young]

Hey @Jack Yaz

Trying to track down an issue with my 2.4G connections resetting every so often. At first, I was thinking it was related to the new 386.4 build, but I finally caught the error networkmap: Error unlocking 11: 9 Bad file descriptor and networkmap: Error unlocking 0: 9 Bad file descriptor in the logs while YazFi is starting up. I have attached the logs below. Was wondering if you have any insights or is a JFFS format in order.

This only happens every couple of hours. It is looking like the firewall-start script is getting called when spdmerlin makes a bandwidth change. Just wondering if this is expected, and if so, could it be related to the issues some are having on the new 386.4 build? Does not not seem to bother my system at all.

Any other logs I can send you?

Cheers

Jan  6 14:12:00 RTAC86U spdMerlin: Starting speedtest using Eastlink (Barrie, ON, Canada) for WAN interface
Jan  6 14:12:26 RTAC86U spdMerlin: Speedtest results - Download: 75.58 Mbps (data used: 92.7 MB ) - Upload: 38.92 Mbps (data used: 42.2 MB )
Jan  6 14:12:26 RTAC86U spdMerlin: Connection quality - Latency: 32.58 ms (19.27 ms jitter) - Packet Loss: 0.6%
Jan  6 14:12:26 RTAC86U spdMerlin: Retrieving data for WebUI charts
Jan  6 14:12:32 RTAC86U spdMerlin: Calculated Download speed (72994 Kbps) does not exceed 5% threshold of existing value (73210 Kbps)
Jan  6 14:12:32 RTAC86U spdMerlin: Calculated Upload speed (35211 Kbps) does not exceed 5% threshold of existing value (36455 Kbps)
Jan  6 15:12:00 RTAC86U spdMerlin: Starting speedtest using Eastlink (Barrie, ON, Canada) for WAN interface
Jan  6 15:12:27 RTAC86U spdMerlin: Speedtest results - Download: 75.82 Mbps (data used: 92.9 MB ) - Upload: 31.22 Mbps (data used: 38.3 MB )
Jan  6 15:12:27 RTAC86U spdMerlin: Connection quality - Latency: 25.52 ms (8.99 ms jitter) - Packet Loss: 0.0%
Jan  6 15:12:27 RTAC86U spdMerlin: Retrieving data for WebUI charts
Jan  6 15:12:35 RTAC86U spdMerlin: Calculated Download speed (72913 Kbps) does not exceed 5% threshold of existing value (73210 Kbps)
Jan  6 15:12:35 RTAC86U spdMerlin: Setting QoS Upload Speed to 34400 Kbps (was 36455 Kbps)
Jan  6 15:12:35 RTAC86U rc_service: service 21156:notify_rc restart_qos;restart_firewall
Jan  6 15:12:35 RTAC86U custom_script: Running /jffs/scripts/service-event (args: restart qos)
Jan  6 15:12:35 RTAC86U custom_script: Running /jffs/scripts/service-event (args: restart firewall)
Jan  6 15:12:35 RTAC86U custom_script: Running /jffs/scripts/nat-start
Jan  6 15:12:35 RTAC86U ntpMerlin: Sleeping for 5s to allow firewall/nat startup to be completed...
Jan  6 15:12:35 RTAC86U custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Jan  6 15:12:36 RTAC86U YazFi: Firewall restarted - sleeping 10s before running YazFi
Jan  6 15:12:40 RTAC86U conntrackscript: Value 750 written to nf_conntrack_expect_max, restarting conntrack
Jan  6 15:12:42 RTAC86U rc_service: service 21448:notify_rc restart_conntrack
Jan  6 15:12:42 RTAC86U custom_script: Running /jffs/scripts/service-event (args: restart conntrack)
Jan  6 15:12:42 RTAC86U (nat-start): 21305 Checking if WireGuard is UP....
Jan  6 15:12:46 RTAC86U YazFi: YazFi v4.4.0 starting up
Jan  6 15:12:47 RTAC86U YazFi: wl0.1 (SSID: YoungRestrict) - sending all interface internet traffic over WAN interface
Jan  6 15:12:50 RTAC86U YazFi: Executing user script: /jffs/addons/YazFi.d/userscripts.d/add_post_printer.sh
Jan  6 15:12:50 RTAC86U YazFi: Forcing YazFi Guest WiFi clients to reauthenticate
Jan  6 15:13:01 RTAC86U networkmap: Error unlocking 11: 9 Bad file descriptor
Jan  6 15:13:01 RTAC86U networkmap: Error unlocking 0: 9 Bad file descriptor
Jan  6 15:13:06 RTAC86U YazFi: YazFi v4.4.0 completed successfully

 

[ColinTaylor]

Trying to track down an issue with my 2.4G connections resetting every so often. At first, I was thinking it was related to the new 386.4 build, but I finally caught the error networkmap: Error unlocking 11: 9 Bad file descriptor and networkmap: Error unlocking 0: 9 Bad file descriptor in the logs while YazFi is starting up.

Those are perfectly normal messages and don't indicate a problem. They occur every time the wireless system is (re)started. You don't normally see them because they are at debug level, so you need to change the log level for them to appear in the log.

 

[Jeffrey Young]

Thanks @ColinTaylor. Good to know. I am using scribe, so I don't know if I can change the notification level. The scribe GUI has no setting for it. Tis OK, as long as it is explained.

For myself, the 386.4 release has been working great - even with the tp-link IOT devices. It was just the first I've noticed the 2.4G connection times reset.

Cheers

 

[Jeffrey Young]

I'll try the nvram variable log_level. It is currently at 6. I'll raise it to a higher number and see if scribe changes at all.

 

[ColinTaylor]

I'll try the nvram variable log_level. It is currently at 6. I'll raise it to a higher number and see if scribe changes at all.

Sorry, I don't understand what you're trying to achieve.

 

[Jack Yaz]

YazFi kills networkmap to clear out any devices that might linger with an incorrect IP

 

[Jeffrey Young]

Scribe does not have an option to set the kernel log level in the GUI. Currently, the nvram variable log_level is set to 6 (information). Was hoping that setting the log_level to a high number, say 5 (notice), it will get rid of the useless stuff in the log.

For the time being, I've disabled the auto bandwidth adjust in SpdMerlin so as not to slam the 2.4G devices while I test drive 386.4.

 

[Jeffrey Young]

YazFi kills networkmap to clear out any devices that might linger with an incorrect IP

Thanks Jack. Just had me going there a bit trying to figure out if the 2.4G connection times were being reset as part of the other issues people are seeing with 386.4 or something else.

386.4 for me has been good. Even with tp-link switches.

 

[Jack Yaz]

Scribe does not have an option to set the kernel log level in the GUI. Currently, the nvram variable log_level is set to 6 (information). Was hoping that setting the log_level to a high number, say 5 (notice), it will get rid of the useless stuff in the log.

For the time being, I've disabled the auto bandwidth adjust in SpdMerlin so as not to slam the 2.4G devices while I test drive 386.4.

uiScribe hides that option "log levels more than", I'm going to restore it since it does apply after all