[RT-AX86U] bridge-mode: disconnects at the same time but changed after update

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

airgap

Occasional Visitor
Hi guys,

I know the subject title sound a bit weird but I didn't know how to describe it better - so if it is misleading or not very well chosen please provide me some sugestions and I will change it.

So I had here a thread where I issues with the wifi schedule (you will find it over my profile I guess) but then I decided to deactivate it on my both routers about 2 months ago because I gave hope on ASUS fixing it and I changed it "solved" because there is no option as "close unsolved" :D

Bare with me for a second I will come to the point but first a short summary for the people who didn't read my other thread about my setup:

I have exactly 2 routers and one is configured as normal router (lets call it main router) with WAN access and the other is in bridge-mode (let call it bridge-router).

Now the issue:
After deactivating the schedulers on wifi the bridge-router for some odd reasons the LAN and WIFI worked for 2 days and then went off always on the same time (about 4pm) which was very weird.
Then there was the update 3.0.0.4.386_42840 which I installed it and then it disconnected everything at 5pm.
At the weekend I just tried to config the bridge-router as a repeater just to check some issues with my laptop and then tried the mesh feature to see what that is about.
For the mesh config it set my router back to factory reset etc. I checked the wifi-mesh but it was use less for me and I lost a lot of network speed so I switched back.
But know the disconnect happen at 6pm o_O hahaha I can't wrap my head around this - wth is this?

Code:
May 12 17:18:54 kernel: kck:
May 12 17:18:54 kernel:   0000: 88 0f 9c 82 e6 db 1c 06 dc 8a 15 11 c7 6a ce 6a
May 12 17:18:54 kernel: kek:
May 12 17:18:54 kernel:   0000: 00 94 1a c3 17 69 f3 3a 72 a2 29 1d c5 13 6b db
May 12 17:18:54 kernel: replay_ctr:
May 12 17:18:54 kernel:   0000: 00 00 00 00 00 00 00 0e
May 12 18:02:25 rc_service: psta_monitor 31511:notify_rc restart_wlcmode 0
May 12 18:02:25 FTP Server: daemon is stopped
May 12 18:02:25 Samba Server: smb daemon is stoped
May 12 18:02:27 kernel: dpsta_register: null dpsta_ifnames!
May 12 18:02:34 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) (phyId: b) Link DOWN.
May 12 18:02:34 RT-AX86U: start https:8443
May 12 18:02:34 RT-AX86U: start httpd:80
May 12 18:02:34 httpd: Save SSL certificate...80
May 12 18:02:34 httpd: mssl_cert_key_match : PASS
May 12 18:02:34 httpd: Succeed to init SSL certificate...80
May 12 18:02:34 httpd: Succeed to init SSL certificate...8443
May 12 18:02:34 rc_service: psta_monitor 31511:notify_rc restart_wireless
May 12 18:02:34 kernel: ===> Activate Deep Green Mode
May 12 18:02:34 kernel: bcmswlpbk0 (Ext switch port: 8) (Logical Port: 8) Virtual link DOWN
May 12 18:02:37 get_ext_phy_id: 0/1/0/0
May 12 18:02:37 kernel: dpsta_register: null dpsta_ifnames!
May 12 18:02:38 kernel: <=== Deactivate Deep Green Mode
May 12 18:02:38 kernel: bcmswlpbk0 (Ext switch port: 8) (Logical Port: 8) Virtual link UP
May 12 18:02:38 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) (phyId: b) Link Up at 1000 mbps full duplex
May 12 18:02:40 dnsmasq-dhcp[24612]: no address range available for DHCP request via br0
May 12 18:02:41 kernel: dpsta_register: null dpsta_ifnames!
May 12 18:02:41 kernel: kck:
May 12 18:02:41 kernel:   0000: 3a 22 a2 2a 44 3b 58 4c 27 a9 7a 73 ff 22 1f 2c
May 12 18:02:41 kernel: kek:
May 12 18:02:41 kernel:   0000: 43 77 91 2c e6 aa 8d b9 89 b7 e0 15 00 37 c7 b1
May 12 18:02:41 kernel: replay_ctr:
May 12 18:02:41 kernel:   0000: 00 00 00 00 00 00 00 02
May 12 18:02:45 dnsmasq-dhcp[24612]: no address range available for DHCP request via br0
May 12 18:02:48 rc_service: psta_monitor 24747:notify_rc restart_wlcmode 1
May 12 18:02:48 FTP Server: daemon is stopped
May 12 18:02:48 Samba Server: smb daemon is stoped
May 12 18:02:56 RT-AX86U: start https:8443
May 12 18:02:56 RT-AX86U: start httpd:80
May 12 18:02:56 httpd: Save SSL certificate...8443
May 12 18:02:57 httpd: mssl_cert_key_match : PASS
May 12 18:02:57 httpd: Succeed to init SSL certificate...8443
May 12 18:02:57 httpd: Succeed to init SSL certificate...80
May 12 18:02:57 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) (phyId: b) Link DOWN.
May 12 18:02:58 kernel: ===> Activate Deep Green Mode
May 12 18:02:58 kernel: bcmswlpbk0 (Ext switch port: 8) (Logical Port: 8) Virtual link DOWN
May 12 18:03:01 kernel: <=== Deactivate Deep Green Mode
May 12 18:03:01 kernel: bcmswlpbk0 (Ext switch port: 8) (Logical Port: 8) Virtual link UP
May 12 18:03:01 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) (phyId: b) Link Up at 1000 mbps full duplex
May 12 18:18:54 kernel: kck:
May 12 18:18:54 kernel:   0000: 3a 22 a2 2a 44 3b 58 4c 27 a9 7a 73 ff 22 1f 2c
May 12 18:18:54 kernel: kek:
May 12 18:18:54 kernel:   0000: 43 77 91 2c e6 aa 8d b9 89 b7 e0 15 00 37 c7 b1
May 12 18:18:54 kernel: replay_ctr:
May 12 18:18:54 kernel:   0000: 00 00 00 00 00 00 00 03

It all starts always with the:
May 12 18:02:25 rc_service: psta_monitor 31511:notify_rc restart_wlcmode 0

Anybody having the same issue with bridge-mode? Any ideas what might cause that and how to fix it?

Thank you :)
 

airgap

Occasional Visitor
OK now I am totaly lost o_O:D let me explain.

I said to myself: "Hey what about just shut the bridge-router off and unplug the power cable for an entire day."

Now the random disconnects shiftet to another time.

This time it occurs at 11am and 11pm

WTH? What kind of easter egg is this ASUS?????????? :D even though it's kind of funny but it's in the end not funny.

No one facing this kind of weird issue?
 

airgap

Occasional Visitor
Well I have a bit more time now for investigating on this issue and I found out that this issue is exactly related to the last time it booted up / rebooted.
That's strange. I don't know what causes that issue o_O

It all starts always with that (according to log):

Bash:
rc_service: psta_monitor 31511:notify_rc restart_wlcmode 0

I don't get why it is always trying to force wlcmode 0 on that specific time where the system booted up.

Is there a good documentation about these stupid services and process which ASUS use? I guess not but may be someone knows more on this :)

I am still investigating and trying to find out if there is a solution but I think that this might be something which the ASUS DEVs have to fix.
 

airgap

Occasional Visitor
well another good finding:

I just tried to look for some information about the psta_monitor and I suddenly find a lot of people with ASUS routers complaining about the same behaviour when it's set to bridge-mode.

I don't know if I am allowed to link to other websites but I found some here in SNB-Forum:

(look from post 25 on)



Sooooooo.......ASUS messed up and I guess there is absolutely nothing that I can do or fix this issue :(



UPDATE:
I changed the title and added "bridge-mode" to the subject. May be that helps others to find it better which have the same issue and I tagged it with "bridge mode".
 

airgap

Occasional Visitor
OK I just monitored a workaround and it seems to work. Of course until a reboot or restart of the init service but it might help for a while until a magic happens and ASUS finds out what they messed up.

The workaround is simply I note it for people who are not familiar with unix systems.
You need SSH access to your router.

1. just figure out the PID (process ID)
Bash:
ps | grep psta_monitor | grep -v grep

explanation:
ps = lists all running processes
| = a pipe for giving the result to the next command or combine with the next command
grep psta_monitor = filters (is grepping) for everything with the word "psta_monitor"
grep -v grep = inverting the grep which means don't show entries with the word "grep" otherwise ps will show you even the PID for the grep it self.

result should be something like this:
Bash:
26925 admin     3192 S    psta_monitor

the first column (in this case 26925) is the PID of that process which is called psta_monitor.

Generaly in UNIX:
It's good common sense: You have to check everytime the process ID of the process which you want to kill!
Sometimes other process might start or restart and get the same old PID of the other process and if you just blindly type in the same number you will kill another process.

2. now kill the process
Code:
kill 26925

explanation:
kill = kills the process with the PID 26925.

It's safe and does no harm as far as I observed. Everything works fine. No disconnects at the specific times when it would normaly disconnect.


Hope this might help a little bit. I know it's not the best solution but it's a good solution without any bad consequences by now. May be ASUS will fix it soon.
 

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