What's new

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

  • 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!

airgap

Regular Contributor
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 :)
 
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?
 
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.
 
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".
 
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.
 
Sorry to bump this thread, did you find anything else? I have been looking into a fix for such a long time.... I cannot believe this is still an issue from the date of your post .........
 
Sorry but no ... I didn't dig further because I could pinpoint it to the psta_monitor and my workaround "solves" it for a while.

As I said this is something which ASUS messed up and they have to fix it but I am sure it won't happen and IF ... not soon :D

IMHO: as usual way of life from a vendor ... release something which is still needs improvements but grab money from buyers and then from time to give them some bugfix otherwise they will complain a lot won't buy your s**** anymore and your reputation goes down ... BUT don't invest to much to make it almost perfect otherwise nobody has a reason to buy your newest products.

So there is no other way then to wait.
 
Anyways, I’ve put a script in flash which gets executed automagically when a usb stick is seen. I don’t think this will be completely resolved until I change my WIFI to non Asus devices……
 
I don’t think this will be completely resolved until I change my WIFI to non Asus devices……

I understand that but for me my AX-86U is to "perfect" in the other parts which I use rather to ditch it because of that stupid bug which ASUS should fix it and not we as customers and users! I will still use my routers for at least 2 years. Then may be I switch or ASUS somehow found this thread and decided to fix it - I hope but I don't rely on it.
 
Why exactly do you have to use bridge mode?

I don't have to but I chose to use it because of following paramters:

1.) My computer has no WiFi and I don't want to lay x-meters of LAN cable to the living room (and I don't want to drill holes everywhere to put cables through)
2.) because of 1 I looked out for the a good router which has good balance between price and performance and I came to the conclusion to buy exactly what I have now.

I have more than enough speed (my LAN is bottleneck now lol) and I am fully satisfied. I tested repeater mode and etc. but the best mode for me was and still is bridge-mode.

I like my setup and everything works very well for me - except that bug which I solved with my workaround. I don't have to reboot my routers they can stay for weeks and months without reboot.

So I would recommend the AX-86U anytime if someone like to set it up like me.

Hope I could answer your question as good as possible.
 
The AX86U is definitely a high performance choice for a router. I don't know what brand or type the other router in your two router setup is but I would think that anything else except for another AX86U or equivalent performer would be a performance bottleneck.

With networking topography usually the most simple setup is the way to go. It's good you have found a setup that you believe works for you since you obviously know more about your setup than anyone else. There are so many other options available but if you are convinced that bridge mode is what works best then there is not much more that can said about that. Good luck and let us know if you make any future changes that you find would be an improvement.
 
I have two AX-86U :D
and did my research before buying them and I knew that both of them would make a perfect match and I was right about that :)
Sure I will be available in the forum and write from time to time to topics.

EDIT:
I didn't change the topic header to "solved". It is not solved. I guess it can be tagged as solved when ASUS provide the fix.
But for me it is done for now because I have my workaround and that's ok for me.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top