Release Asuswrt-Merlin 386.1 is now available

[heysoundude]

Discovered another curious thing.

After setting up an AC68U as an AImesh node on 386.1_2, my Samsung S5 battery's life span seems much shorter. Without using the phone (it's just laying around the house) its battery completely drained within 24 hours.
I also notice this happening when using AiMesh 1.0.

Could it be the phone's confused which station to connect to and just keeps flipping? There seems to be not much associating/disassociating going on in system log, only twice a day.

Anyone else noticed this phenomena?

try moving it closer to one of the two wifi sources and see if what you suspect is actually the case. I have one android device on my network and I've found that there's a lot of "phoning home" going on in the background on that phone...try to turn it off if you can narrow it down. I was able to in a couple of cases on that device and it helped

 

[John Adler]

Dirty flash 386.1-2 over 386.1
al seems OK

 

[JonEngland]

thank you for this trick that works perfectly !

I hope that the problem will be solved in future versions with an automatic and regular refresh.

not seeing this behaviour here; what model do you have?
If I disconnect/connect a device from/to the wifi (not tried ethernet connected devices), then the number of clients shown in the gui updates by 1 after about 20-25s without any interaction

 

[ottofreud]

not seeing this behaviour here; what model do you have?
If I disconnect/connect a device from/to the wifi (not tried ethernet connected devices), then the number of clients shown in the gui updates by 1 after about 20-25s without any interaction

Mine is an AX88U

 

[Makaveli]

not seeing this behaviour here; what model do you have?
If I disconnect/connect a device from/to the wifi (not tried ethernet connected devices), then the number of clients shown in the gui updates by 1 after about 20-25s without any interaction

I also do not have this issue.

 

[ottofreud]

I also do not have this issue.

That is odd as we have the same model. I have an AIMesh environment. Maybe that has something to do with it?

 

[JonEngland]

I also do not have this issue.

not the model then, yours is same as ottofreud who does have this issue
maybe difference in 386.1 and 386.1_2? (edit: sig updated)

 

[JonEngland]

That is odd as we have the same model. I have an AIMesh environment. Maybe that has something to do with it?

I have aimesh too
I've withdrawn from the Trend agreement if that's a factor?

 

[ottofreud]

I have aimesh too
I've withdrawn from the Trend agreement if that's a factor?

Perhaps. Can't withdraw at the moment to test. But if i get some low use time this weekend, I'll test it for an hour or so with clients powering on and off.

 

[Kees17760]

try moving it closer to one of the two wifi sources and see if what you suspect is actually the case. I have one android device on my network and I've found that there's a lot of "phoning home" going on in the background on that phone...try to turn it off if you can narrow it down. I was able to in a couple of cases on that device and it helped

I tried to put the phone in different locations and changed nothing to the phone itself. It's barebone

I first experienced it right after installing AiMesh on 384.19. My phone battery suddenly completely drained within 24 hours. Initially i thought the battery reached EOL, so i bought a new one. To my surprise the same thing happened, so i returned it and got another battery. Again the same thing happened, so my suspicion moved to the phone itself.

Anyway, at some point i decided to brake up my router configuration, and only use the AC2900 as my main router. No more AiMesh! From then on the battery problem vanished.

When switching to 386.1_2 i decided to give AiMesh 2 another shot and guess what: the battery thing was back again the very first day.

Funny thing is it does not happen every day and i can't put my finger on it. It's more of a gut feeling.
I don't use my phone much and can easily live with it. I'm just curious if others encounter the same thing

 

[Fred2u]

@Fred2u
Luckily this will be the last time anyone will ever make that mistake, since this Forum is loaded with diligent "searchers" and "readers" that always do clean installs on freshly reset routers.

Stay Safe Everyone

Indeed, Clark! At least this diligent searcher and reader won't make that mistake again. In fact, having recognized the errors of my ways, I meanwhile upgraded to 386.1_2 without problems in a fully reset (and "cleaned") AC86U system. All thanks to LD&L's guides and dave14305's help.

 

[Makaveli]

That is odd as we have the same model. I have an AIMesh environment. Maybe that has something to do with it?

No Ai Mesh on my side.

 

[Goned75]

Because net-snmpd is not compatible with some models, like the RT-AX88U.

Thanks - but I thought the AX86U was identical to the AX88U (apart from the wifi part)

 

[lala_cai]

I'm facing a problem with RT-AC86U where the devices is unable to connect to 2.4GHz after a certain time (from days to weeks). I can see the SSID but it just refused to connect.
I have no problem with 5GHz. This issues seems to begin from 384.18 onwards and now I'm on 386.1_2 and it's still happening.
By the time I notice the problem and view the logs, its already rolled over.

Any method or any logs I can check for the issue?

Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 28:6C:07:B9:00:A2, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 28:6C:07:B9:00:A2, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 28:6C:07:B9:00:A2, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 00:03:7F:77:0D:76, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 00:03:7F:77:0D:76, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 00:03:7F:77:0D:76, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 34:CE:00:FB:63:2C, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 34:CE:00:FB:63:2C, status: Successful (0), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(526): eth5: Auth 34:CE:00:FB:63:2C, status: Successful (0), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0

 

[Frankflash]

I'm facing a problem with RT-AC86U where the devices is unable to connect to 2.4GHz after a certain time (from days to weeks). I can see the SSID but it just refused to connect.
I have no problem with 5GHz. This issues seems to begin from 384.18 onwards and now I'm on 386.1_2 and it's still happening.
By the time I notice the problem and view the logs, its already rolled over.

Any method or any logs I can check for the issue?

Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 28:6C:07:B9:00:A2, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 28:6C:07:B9:00:A2, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 28:6C:07:B9:00:A2, status: Successful (0), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:00 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 00:03:7F:77:0D:76, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 00:03:7F:77:0D:76, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 00:03:7F:77:0D:76, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind 84:D8:1B:20:A6:8F, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 34:CE:00:FB:63:2C, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:01 wlceventd: wlceventd_proc_event(526): eth5: Auth 34:CE:00:FB:63:2C, status: Successful (0), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(526): eth5: Auth 34:CE:00:FB:63:2C, status: Successful (0), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(490): eth5: Deauth_ind B0:95:75:70:B0:4E, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(526): eth5: Auth B0:95:75:70:B0:4E, status: Successful (0), rssi:0
Feb 20 14:46:02 wlceventd: wlceventd_proc_event(526): eth5: Auth 84:D8:1B:20:A6:8F, status: Successful (0), rssi:0

it has been reported many times in forums
just debugging code for asus

 

[lala_cai]

it has been reported many times in forums
just debugging code for asus

Hi,

I'm not talking about the debugging code.
I'm facing an issue whereby 2.4GHz disconnect all the clients and no longer allow connection even though I can see the SSID

I attached the logs to see if there are better ways to troubleshoot the issue.
thanks

 

[Matthew Patrick]

Hi,

I'm not talking about the debugging code.
I'm facing an issue whereby 2.4GHz disconnect all the clients and no longer allow connection even though I can see the SSID

I attached the logs to see if there are better ways to troubleshoot the issue.
thanks

And sometimes it works again? Mine happens on 386 only and it's been fine for weeks on 384.19. I wps reset on 386 and it's still happening. It's basically disconnecting some clients on 2.4ghz and freezing all devices connected to 2.4ghz while not letting any connect to 2.4ghz for minutes at times. Then when it's done doing that it works fine again. And it does that every few minutes. Haven't tried _2 since doesn't seem anything has changed... But yeh it's not a hw issue since 384.19 works just fine for weeks now

 

[Frankflash]

Hi,

I'm not talking about the debugging code.
I'm facing an issue whereby 2.4GHz disconnect all the clients and no longer allow connection even though I can see the SSID

I attached the logs to see if there are better ways to troubleshoot the issue.
thanks

only Asus can fix it you should send logs to asus wifi is closed scorce and Merlin cant fix it

 

[lala_cai]

And sometimes it works again? Mine happens on 386 only and it's been fine for weeks on 384.19. I wps reset on 386 and it's still happening. It's basically disconnecting some clients on 2.4ghz and freezing all devices connected to 2.4ghz while not letting any connect to 2.4ghz for minutes at times. Then when it's done doing that it works fine again. And it does that every few minutes. Haven't tried _2 since doesn't seem anything has changed... But yeh it's not a hw issue since 384.19 works just fine for weeks now

Nope, it will not work again as I have camera which reports to the cloud which will notify me it has been disconnected for 30 minutes.
On the 384.19, it will still happen once maybe in weeks but not as frequent as 386 (in days).

 

[Wishmaster1965]

Was hoping to test openVPN today after the new update to 386.1.2 but no devices can connect back to home. Upon checking the router its missing the tun interfaces

Tried a reboot to no effect. So looks like I will have to rebuild the router from scratch again.