What's new

[ 3004.388.6 alpha Build(s) ] Testing available build(s)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
No, the problem did not exist under 388.5.
You could have posted this A LITTLE sooner... ;)
I just downgraded to 388.5 and verified that the error wasn't there.
 
AX86u Pro here - everything working flawlessly after dirty flash.
Wireguard, OpenVPN, VPN Director, guest wifi etc.
All my wacky settings are running without any issues.
 
Last edited:
Spoke too soon.. Happened a couple of times today, no crash but the Bandwidth Monitor and Data Classification started up with the BWDPI Engine

Dec 27 15:24:00 Router kernel: Init chrdev /dev/idp with major 190
Dec 27 15:24:00 Router kernel: tdts: tcp_conn_max = 8000
Dec 27 15:24:00 Router kernel: tdts: tcp_conn_timeout = 300 sec
Dec 27 15:24:01 Router kernel: SHN Release Version: 2.0.2 36f59aa
Dec 27 15:24:01 Router kernel: UDB Core Version: 0.2.20
Dec 27 15:24:01 Router kernel: Init chrdev /dev/idpfw with major 191
Dec 27 15:24:01 Router kernel: IDPfw: flush fc
Dec 27 15:24:01 Router kernel: IDPfw: IDPfw is ready
Dec 27 15:24:01 Router kernel: sizeof forward pkt param = 280
Dec 27 15:24:01 Router BWDPI: fun bitmap = 3
Dec 27 15:24:26 Router BWDPI: force to flush flowcache entries
Dec 27 15:24:26 Router kernel: IDPfw: Exit IDPfw
Dec 27 15:24:26 Router kernel: mod epilog takes 0 jiffies
Dec 27 15:24:26 Router kernel: IDPfw: Exit IDPfw
Dec 27 15:24:26 Router kernel: Exit chrdev /dev/idpfw with major 191
Dec 27 15:24:26 Router kernel: Exit chrdev /dev/idp with major 190

This was the same thing that was zapping my bandwith when the QoS settings were set (even though QoS is disabled) and would kick in. Hadn't happened in 388.5 and fortunately I have the QoS rules cleared out, so only saw it by monitoring the logs if only to stay on top of the new release. It wasn't working before (only for a short time after reboot), but now Bandwidth Monitor and Data Classfication (until automatic 3 second refresh) are on all the time all the time.
 
Ax 6000 here i see i am getting this message over and over


Dec 27 19:14:09 rc_service: watchdog 2704:notify_rc stop_aae
Dec 27 19:14:09 rc_service: watchdog 2704:notify_rc start_mastiff
Dec 27 19:14:09 rc_service: waitting "stop_aae" via watchdog ...
Dec 27 19:14:10 Mastiff: init
Dec 27 19:14:40 rc_service: watchdog 2704:notify_rc stop_aae
Dec 27 19:14:40 rc_service: watchdog 2704:notify_rc start_mastiff
Dec 27 19:14:40 rc_service: waitting "stop_aae" via watchdog ...
Dec 27 19:14:41 Mastiff: init


forget about it did a full reset now all works
 
Last edited:
Spoke too soon.. Happened a couple of times today, no crash but the Bandwidth Monitor and Data Classification started up with the BWDPI Engine

Dec 27 15:24:00 Router kernel: Init chrdev /dev/idp with major 190
Dec 27 15:24:00 Router kernel: tdts: tcp_conn_max = 8000
Dec 27 15:24:00 Router kernel: tdts: tcp_conn_timeout = 300 sec
Dec 27 15:24:01 Router kernel: SHN Release Version: 2.0.2 36f59aa
Dec 27 15:24:01 Router kernel: UDB Core Version: 0.2.20
Dec 27 15:24:01 Router kernel: Init chrdev /dev/idpfw with major 191
Dec 27 15:24:01 Router kernel: IDPfw: flush fc
Dec 27 15:24:01 Router kernel: IDPfw: IDPfw is ready
Dec 27 15:24:01 Router kernel: sizeof forward pkt param = 280
Dec 27 15:24:01 Router BWDPI: fun bitmap = 3
Dec 27 15:24:26 Router BWDPI: force to flush flowcache entries
Dec 27 15:24:26 Router kernel: IDPfw: Exit IDPfw
Dec 27 15:24:26 Router kernel: mod epilog takes 0 jiffies
Dec 27 15:24:26 Router kernel: IDPfw: Exit IDPfw
Dec 27 15:24:26 Router kernel: Exit chrdev /dev/idpfw with major 191
Dec 27 15:24:26 Router kernel: Exit chrdev /dev/idp with major 190

This was the same thing that was zapping my bandwith when the QoS settings were set (even though QoS is disabled) and would kick in. Hadn't happened in 388.5 and fortunately I have the QoS rules cleared out, so only saw it by monitoring the logs if only to stay on top of the new release. It wasn't working before (only for a short time after reboot), but now Bandwidth Monitor and Data Classfication (until automatic 3 second refresh) are on all the time all the time.
So what you observe ; with all QoS functions disabled you still see activity in the "Bandwidth Monitor" when opening the tab "Adaptative QoS" and at the same time those kernel messages do show in the logging?
With my AX88u and latest firmware I have exact the same behavior and the same messages in the logging.
Code:
Dec 27 13:47:22 kernel: Init chrdev /dev/idp with major 190
Dec 27 13:47:22 kernel: tdts: tcp_conn_max = 8000
Dec 27 13:47:22 kernel: tdts: tcp_conn_timeout = 300 sec
Dec 27 13:47:24 kernel: SHN Release Version: 2.0.2 36f59aa
Dec 27 13:47:24 kernel: UDB Core Version: 0.2.20
Dec 27 13:47:24 kernel: Init chrdev /dev/idpfw with major 191
Dec 27 13:47:24 kernel: IDPfw: flush fc
Dec 27 13:47:24 kernel: IDPfw: IDPfw is ready
Dec 27 13:47:24 kernel: sizeof forward pkt param = 280
Dec 27 13:47:24 BWDPI: fun bitmap = 3
Dec 27 13:47:32 rc_service: httpd 1197:notify_rc restart_qos;restart_firewall
Dec 27 13:47:32 custom_script: Running /jffs/scripts/service-event (args: restart qos)
Dec 27 13:47:33 BWDPI: force to flush flowcache entries
Dec 27 13:47:33 kernel: IDPfw: Exit IDPfw
Dec 27 13:47:33 kernel: mod epilog takes 0 jiffies
Dec 27 13:47:33 kernel: IDPfw: Exit IDPfw
Dec 27 13:47:33 kernel: Exit chrdev /dev/idpfw with major 191
Dec 27 13:47:33 kernel: Exit chrdev /dev/idp with major 190
Dec 27 13:47:33 BWDPI: rollback fc
Dec 27 13:47:33 kernel: Cpuidle Host Clock divider is enabled
Dec 27 13:47:33 custom_script: Running /jffs/scripts/service-event-end (args: restart qos)
Dec 27 13:47:33 custom_script: Running /jffs/scripts/service-event (args: restart firewall)
Dec 27 13:47:34 custom_script: Running /jffs/scripts/service-event-end (args: restart firewall)

I did find a temporary workaround until a next reboot of the router.
Open the "Adaptative QoS" - "Bandwidth Monitor" tab (all QoS functions disabled) , scroll down to the bottom and hit the Apply button. Let the GUI does it work and don't change to an other tab. When the GUI is settled , scroll down again and hit Apply a second time and let it settle.
The log will still show the kernel messages you mentioned, but after the workaround no more messages when opening the "Adaptative QoS" - "Bandwidth Monitor" tab should be seen in the logging.
 
So what you observe ; with all QoS functions disabled you still see activity in the "Bandwidth Monitor" when opening the tab "Adaptative QoS" and at the same time those kernel messages do show in the logging?
With my AX88u and latest firmware I have exact the same behavior and the same messages in the logging.
Code:
Dec 27 13:47:22 kernel: Init chrdev /dev/idp with major 190
Dec 27 13:47:22 kernel: tdts: tcp_conn_max = 8000
Dec 27 13:47:22 kernel: tdts: tcp_conn_timeout = 300 sec
Dec 27 13:47:24 kernel: SHN Release Version: 2.0.2 36f59aa
Dec 27 13:47:24 kernel: UDB Core Version: 0.2.20
Dec 27 13:47:24 kernel: Init chrdev /dev/idpfw with major 191
Dec 27 13:47:24 kernel: IDPfw: flush fc
Dec 27 13:47:24 kernel: IDPfw: IDPfw is ready
Dec 27 13:47:24 kernel: sizeof forward pkt param = 280
Dec 27 13:47:24 BWDPI: fun bitmap = 3
Dec 27 13:47:32 rc_service: httpd 1197:notify_rc restart_qos;restart_firewall
Dec 27 13:47:32 custom_script: Running /jffs/scripts/service-event (args: restart qos)
Dec 27 13:47:33 BWDPI: force to flush flowcache entries
Dec 27 13:47:33 kernel: IDPfw: Exit IDPfw
Dec 27 13:47:33 kernel: mod epilog takes 0 jiffies
Dec 27 13:47:33 kernel: IDPfw: Exit IDPfw
Dec 27 13:47:33 kernel: Exit chrdev /dev/idpfw with major 191
Dec 27 13:47:33 kernel: Exit chrdev /dev/idp with major 190
Dec 27 13:47:33 BWDPI: rollback fc
Dec 27 13:47:33 kernel: Cpuidle Host Clock divider is enabled
Dec 27 13:47:33 custom_script: Running /jffs/scripts/service-event-end (args: restart qos)
Dec 27 13:47:33 custom_script: Running /jffs/scripts/service-event (args: restart firewall)
Dec 27 13:47:34 custom_script: Running /jffs/scripts/service-event-end (args: restart firewall)

I did find a temporary workaround until a next reboot of the router.
Open the "Adaptative QoS" - "Bandwidth Monitor" tab (all QoS functions disabled) , scroll down to the bottom and hit the Apply button. Let the GUI does it work and don't change to an other tab. When the GUI is settled , scroll down again and hit Apply a second time and let it settle.
The log will still show the kernel messages you mentioned, but after the workaround no more messages when opening the "Adaptative QoS" - "Bandwidth Monitor" tab should be seen in the logging.

The temporary workaround seemed to do the trick, after hitting the apply the second time Bandwidth Monitor shut down and nothing under Data Classification except "Note: Statistics require Traditional QoS mode or the TrendMicro bwdpi engine to be enabled." as it should (note all QoS and App Analysis was and is off) and the System Log has the same messages I originally posted,

Dec 28 09:59:54 Router rc_service: httpd 1346:notify_rc restart_qos;restart_firewall
Dec 28 09:59:54 Router custom_script: Running /jffs/scripts/service-event (args: restart qos)
Dec 28 09:59:56 Router BWDPI: force to flush flowcache entries
Dec 28 09:59:56 Router kernel: IDPfw: Exit IDPfw
Dec 28 09:59:56 Router kernel: mod epilog takes 0 jiffies
Dec 28 09:59:56 Router kernel: IDPfw: Exit IDPfw
Dec 28 09:59:56 Router kernel: Exit chrdev /dev/idpfw with major 191
Dec 28 09:59:56 Router kernel: Exit chrdev /dev/idp with major 190
Dec 28 09:59:56 Router BWDPI: rollback fc
Dec 28 09:59:56 Router kernel: Cpuidle Host Clock divider is enabled
Dec 28 09:59:56 Router custom_script: Running /jffs/scripts/service-event (args: restart firewall)
Dec 28 09:59:56 Router custom_script: Running /jffs/scripts/nat-start
Dec 28 09:59:56 Router custom_script: Running /jffs/scripts/firewall-start (args: eth0)

Great find!
 
No. No AC class router has 388.xxx level firmware (now or ever).
 
I do Get
Dec 28 10:31:28 dnsmasq-dhcp[10043]: DHCPSOLICIT(br0) 00:03:00:01:68:14:01:18:2f:a9
Every 1 Min Dont know what it is.
 
@MrBeer
Did you perform a factory reset after upgrading?
 
upgraded from stable to alpha
388.5
to
388.6

i now also see a wireless driver firmware version change
1703788579249.png




in this release speedtest still not working is that change not committed to this one yet ?
 
Last edited:
@MrBeer
Did you perform a factory reset after upgrading?
yes


Been playing around but i think i know where all the problems are coming from it is the andrid app if i don't conect to the app no error message.
you can use to app but do no link it to a account. This is on the AX6000 but not the AX86u


Can someone tell me what ithis is?
Dec 28 12:57:38 rc_service: httpd 4552:notify_rc restart_logger
Dec 28 12:57:38 syslogd exiting
Dec 28 12:57:38 syslogd started: BusyBox v1.25.1
Dec 28 12:57:38 kernel: klogd started: BusyBox v1.25.1 (2023-12-24 01:41:24 EST)
Dec 28 12:57:43 dnsmasq-dhcp[6034]: DHCPSOLICIT(br0) 00:01:00:01:24:fc:d9:25:d8:cb:8a:ee:9c:e9
Dec 28 12:58:15 dnsmasq-dhcp[6034]: DHCPSOLICIT(br0) 00:01:00:01:24:fc:d9:25:d8:cb:8a:ee:9c:e9
Dec 28 12:59:27 dnsmasq-dhcp[6034]: DHCPSOLICIT(br0) 00:03:00:01:68:14:01:18:2f:a9
Dec 28 13:01:27 dnsmasq-dhcp[6034]: DHCPSOLICIT(br0) 00:03:00:01:68:14:01:18:2f:a9


Fix it it was the printer. printer was ip6 disable it and all error gone.
 
Last edited:
what does this mean
View attachment 55175

is that normal for the WAN connection ?
Yep, totally normal. MDI-X cables have the orange and green pairs swapped at one end - a crossover cable. Modern devices detect MDI-X automatically. Having "unknown" there likely means no test was done as the connection worked off the bat, or there's no cable connected.
 
Mobile devices will connect but "no internet access" with DNS over TLS turned on. Power cycled, same result. tried re-adding DNS to DoT list. Same result. Reverting.
 
Mobile devices will connect but "no internet access" with DNS over TLS turned on. Power cycled, same result. tried re-adding DNS to DoT list. Same result. Reverting.
What model of router are you using? Do you install the last version of alpha on it? Last alpha doesn't have any problems with DNS-over-TLS.
 
these error messages are new to me


Dec 30 14:42:13 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:13 rc_service: udhcpc_wan 355345:notify_rc start_dhcp6c
Dec 30 14:42:13 rc_service: waitting "start_dnsmasq" via watchdog ...
Dec 30 14:42:13 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:14 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:14 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:15 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:15 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:16 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:17 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:17 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:18 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:18 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:19 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:19 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:20 kernel: Serdes 8 False Link Up with Error Symbol 0x4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:20 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:21 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:22 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:22 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:23 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:23 kernel: Serdes 8 False Link Up with Error Symbol 0x4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:23 kernel: ^[[0;30;103mWarning: Serdes at 8 link does not go up following external copper PHY at 21.^[[0m
Dec 30 14:42:24 kernel: eth5 (Int switch port: 7) (Logical Port: 7) (phyId: 15) Link Up at 2500 mbps full duplex
 
Status
Not open for further replies.

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