Dedel66
Senior Member
You could have posted this A LITTLE sooner...No, the problem did not exist under 388.5.
I just downgraded to 388.5 and verified that the error wasn't there.
You could have posted this A LITTLE sooner...No, the problem did not exist under 388.5.
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?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.
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)
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.
yes@MrBeer
Did you perform a factory reset after upgrading?
Only the RT-AX88U build was generated following the fix.in this release speedtest still not working is that change not committed to this one yet ?
thx for the fast response not a critical issue thoOnly the RT-AX88U build was generated following the fix.
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.
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.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.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!