I was looking at the system log in Luci while working on another issue and I noticed the entire log is spammed with these messages, repeating every 9 seconds:
I know this is an old thread, but I want to add that in my case the error didn’t appear when using 3.215. It started after a couple of days of upgrading to 3.216.
System log:
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297196] ipt_ECN ipheth ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_itu_t crc_ccitt compat_xtables cdc_wdm cdc_acm xt_u32 fuse sch_multiq em_nbyte sch_cbq sch_prio sch_pie sch_gred em_meta sch_dsmark sch_teql em_cmp cls_basic act_ipt em_text act_police sch_codel sch_red sch_fq act_connmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress xt_set ip_set_list_set ip_set_hash_netiface ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set ip6t_NPT ip6t_MASQUERADE nf_nat_masquerade_ipv6 ip6table_nat
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297463] nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6t_REJECT nf_reject_ipv6 ip6table_mangle ip6table_filter ip6_tables ip6_udp_tunnel udp_tunnel tun vfat fat ntfs nls_utf8 nls_iso8859_1 sha1_generic ecb sf16a18_hb_fmac sf16a18_lb_fmac cfg80211 compat sf16a18_rf startcore uas sgmac sf_eswitch sfhnat sfax8_netlink ehci_platform sd_mod ext4 jbd2 mbcache exfat button_hotplug mii crc32c_generic sfax8_factory_read
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297617] CPU: 3 PID: 3105 Comm: gltertf Not tainted 4.14.90 #27
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297626] Stack : 00000000 00000008 8054ee84 8017e198 80860000 807e6a7c 00000000 00000000
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297660] 8079caf8 8578993c 84cb1a24 8082b7e7 80796a9c 00000001 857898e0 b290cdfd
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297693] 00000000 00000000 808c0000 00010000 00000000 00000318 00000001 00000000
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297725] 00000000 80830000 00000317 808c0000 80000000 80860000 00000000 86d051d4
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297757] 00000009 0000047a 85789cb4 00000008 00000002 80820000 0000000c 808b000c
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297790] ...
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297802] Call Trace:
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297847] [<8010d174>] show_stack+0x58/0x100
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297871] [<8068bf24>] dump_stack+0xe4/0x120
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297897] [<80130a20>] __warn+0xe0/0x114
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.297910] [<80130a84>] warn_slowpath_fmt+0x30/0x3c
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.298000] [<86d051d4>] cfg80211_calculate_bitrate+0x238/0x348 [cfg80211]
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.298086] [<86d33d74>] cleanup_module+0xba4/0xf48 [cfg80211]
Sat Dec 9 08:24:33 2023 kern.warn kernel: [165796.298150] ---[ end trace 89c11054bcfeaa0c ]---
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165849.946681] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165849.959030] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165849.971237] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165849.983925] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165849.996757] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165850.009886] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165850.058060] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165850.063769] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165850.073912] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:27 2023 kern.warn kernel: [165850.083858] siwifi_calculate_legrate invalid legrate: 4
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.425929] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.438714] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.451113] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.463897] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.476384] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.489042] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.570951] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.577231] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.587154] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:45 2023 kern.warn kernel: [165867.597580] siwifi_calculate_legrate invalid legrate: 5
Sat Dec 9 08:25:53 2023 kern.warn kernel: [165876.206971] siwifi_calculate_legrate invalid legrate: 6
Note: invalid legrate takes different values {4,5,6,7}.
Kernel log:
[166642.218145] siwifi_calculate_legrate invalid legrate: 4
[166642.227766] siwifi_calculate_legrate invalid legrate: 4
[166699.964599] lmac[1] ac from statinfo is error,agg_desc is null so change ac 1 to 1(tid: 0)
I suppose we can work like that unless there are errors that force us to restart the unit, but if there’s something that can be improved, you as a vendor should try to push for a solution, or at least mask the error if it’s really harmless.
Actually, according to @yuxin.zou it looks more like a SiFlower’s SDK thing rather than GL.iNet customization wrongdoing, however, since there are several users affected, somebody should look for a more elegant solution than “ignore it”.
If you are absolutely certain about that, you should allow an option to mask that warning.
But being more proactive, a warning about what? what triggers that warning sometimes? what environment variables could be tuned in order to improve the working of the SoC?
Upgrading to the stable firmware 4.3.7 didn’t improve the unwanted log issues. On the contrary, it seems the unwanted messages are more now. I insist, until your provider fix the issue, there should be a way for the log process to ignore it, as my log server is getting full of garbage.
Just noticed, while scanning the environment with a Mikrotik ... the GL.inet SFT 1200 when connected via 5 GHz to another Mikrotik (with WLAN driver) for internet, that is using 20MHz channel width on 2.4GHz and 40 MHz chaneel width on 5 GHz), sends a beacon for it's own 5GHz and 2.4GHz AP function, with a channel width of 40MHz in 2.4 GHz and 80 MHz (eeCe) on 5 GHz band.
The C channel in 5 GHz is correct for the uplink AP (5220/Ce) , but the first 2 ee of the SFT (5220/eeCe) , are not sent by the uplink Mikrotik.
For one radio setting the channel is set by the uplink connection. This 5 GHz connection is 80% OK (CCQ value on Mikrotik) and somewhat usable. When using the 2.4GHz uplink connection for WWAN , this is an unusable link (17% CCQ only), constant disconnects.
40 MHz on 2.4GHz band is not desirable, the 80 MHz in 5GHz seems to be a mismatch here with the uplink.
Workaround for 2.4GHz uplink is force interface to "legacy" (or wifi G mode, not N) , then the 2.4GHz uplink is very stable (CCQ 98-100%)
Just solve this issue on my Opal SFT1200, running only 2.4GHz (5GHz and Guest disabled) by placing the Wiifi setting in 11b/g/n and 20Mhz mode.
It was previously set I donot know why... in 11g/n and 20/40Mhz...
