[384.9_Alpha - builds] Testing all variants.

[infatality]

@RMerlin is that normal? It happens on stock as well.. Happens since last stable stock and your alpha.

Sent from my Pixel 2 XL using Tapatalk

 

[BlueiPhone]

I see "RT-AX88U_384.9_alpha2-g44e55657a_ubi"

in the Alpha folder ... anyone know anything about this?

 

[RMerlin]

@RMerlin is that normal? It happens on stock as well.. Happens since last stable stock and your alpha.

Sent from my Pixel 2 XL using Tapatalk

I can't read a thing out of this screenshot...

 

[infatality]

I can't read a thing out of this screenshot...

dnsmasq[301]: failed to send packet: Operation not permitted

Sent from my Pixel 2 XL using Tapatalk

 

[skeal]

dnsmasq[301]: failed to send packet: Operation not permitted

Sent from my Pixel 2 XL using Tapatalk

What are your DNS settings?

 

[infatality]

What are your DNS settings?

Open dns for both ipv4 and ipv6.. Have tried 1.1.1.1, Google dns and ISP dns.. Still the same.. Only happens when my pixel 2 xl is connected.. None of my other devices have this log spam. before the last stable release.. There wasn't any log spam like this.

Sent from my Pixel 2 XL using Tapatalk

 

[skeal]

Open dns for both ipv4 and ipv6.. Have tried 1.1.1.1, Google dns and ISP dns.. Still the same.. Only happens when my pixel 2 xl.. But before the last stable release.. There wasn't any log spam like this.

Sent from my Pixel 2 XL using Tapatalk

Maybe the pixel has some kind of dedicated DNS.

 

[infatality]

Maybe the pixel has some kind of dedicated DNS.

Private dns is off.

Sent from my Pixel 2 XL using Tapatalk

 

[skeal]

Private dns is off.

Sent from my Pixel 2 XL using Tapatalk

Then I'm pretty sure it is your DNS filtering, conflicting with the Pixel 2. It being the only device having the issue, and that these new devices have interesting DNS built in. IMHO

 

[RMerlin]

I see "RT-AX88U_384.9_alpha2-g44e55657a_ubi"

in the Alpha folder ... anyone know anything about this?

Just a test build that I compiled last night to test a few fixes on my own router, and which I uploaded before going to bed since it was working fine for me.

Finally settled on a final layout for the connection tracking table, and fixed sorting.

 

[Correlor]

Third attempt.... Does anybody have these two problems?

Those on AC5300 and alpha 2.

Do you experience the following?

These log entries:
Jan 22 18:55:14 rc_service: watchdog 333:notify_rc start_cfgsync
Jan 22 18:55:44 rc_service: watchdog 333:notify_rc start_cfgsync
Jan 22 18:56:14 rc_service: watchdog 333:notify_rc start_cfgsync
Jan 22 18:56:44 rc_service: watchdog 333:notify_rc start_cfgsync
Jan 22 18:57:14 rc_service: watchdog 333:notify_rc start_cfgsync
Jan 22 18:57:44 rc_service: watchdog 333:notify_rc start_cfgsync
Jan 22 18:58:14 rc_service: watchdog 333:notify_rc start_cfgsync
Jan 22 18:58:44 rc_service: watchdog 333:notify_rc start_cfgsync
And:

NVRAM usage jumping up and down on the TOOLS page and slowly increasing!

 

[skeal]

Third attempt.... Does anybody have these two problems?

Although I would not recommend resetting to get an alpha going, that is what it sounds like you need. Restore to defaults and hand configure the settings back in. You don't have to worry about jffs as this can be backed up, or left untouched. You may want to consider this.

 

[dave14305]

Then I'm pretty sure it is your DNS filtering, conflicting with the Pixel 2. It being the only device having the issue, and that these new devices have interesting DNS built in. IMHO

I had similar messages last week (not on the Alpha) when I was absentmindedly running DNSBench on a PC while DNSFilter was active on the router. Dumb.

 

[Gitsum]

Just a test build that I compiled last night to test a few fixes on my own router, and which I uploaded before going to bed since it was working fine for me.

Finally settled on a final layout for the connection tracking table, and fixed sorting.

View attachment 15995

Tried this one on my AX88U and couldn't get the 5G radio to work. Tried a reset with initialize box checked still a no go. Plus the router was very sluggish and slow to respond during initial setup after reset. Went back to the ASUS .5640 and 5G radio is back on.

 

[kernol]

Does anyone know whether this alpha/beta build will fix the "Reboot Scheduler" option for clean reboot and umount of USB's?

See this thread https://www.snbforums.com/threads/reboot-scheduler-corrupts-usb-drive.54647/

 

[Correlor]

@skeal

Although I would not recommend resetting to get an alpha going, that is what it sounds like you need. Restore to defaults and hand configure the settings back in. You don't have to worry about jffs as this can be backed up, or left untouched. You may want to consider this.

I did reset the router and they were still there. Back to 384.8_2.

 

[JohnSmith]

Upgrade AC3100 from V384.8_2 Final to V384.9_alpha2-g2c530c696, soft rebooted, and then did a hard reboot. All appears to be working except the following:

- Under "General|Network Map" Clients are back to listing only a few clients on my network, and when you click "View List", Clients disappear and list resets, never showing all clients
- This also resets the clients shown in the "Adaptive QOS | Bandwidth Monitor" section, until it populates again with LAN and Wireless clients.

 

[Gitsum]

Upgrade AC3100 from V384.8_2 Final to V384.9_alpha2-g2c530c696, soft rebooted, and then did a hard reboot. All appears to be working except the following:

- Under "General|Network Map" Clients are back to listing only a few clients on my network, and when you click "View List", Clients disappear and list resets, never showing all clients

I don't understand why this is such a hard thing to fix... It is very annoying to me as well. I want to be able to see everything connected. But I believe it is hard coded in ASUS code and Merlin may not be able to do anything about it.

 

[JohnSmith]

If its hard coded in ASUS code, then ASUS needs to revisit this again, as it started working properly for me back in V384.5 Beta2, and was working all the way up to V384.8_2 Final

 

[FreshJR]

I don't understand why this is such a hard thing to fix... It is very annoying to me as well. I want to be able to see everything connected. But I believe it is hard coded in ASUS code and Merlin may not be able to do anything about it.

As a work around you reliably can view most clients connected via the dhcp table.
The only clients not shown in the DHCP table are the ones who grab a static IP instead of a dhcp lease.

The client map has been slow to fully populate for the last forever (mine always seems to be missing random devices).

I think the reason this happens is because once a device has no more active connections, it is not considered as a active device in the trendmicro device database, even though that device most likely is STILL is actively connected to the network/wifi.
Now get this, THEY ALREADY HAVE IT INTERNALLY FIXED.


If you navigate the firmware, there is different section that queries data from the same connected device database.

AiProtection -> Parental Controls -> Time Scheduling -> Client Name -> Show Offline Client List
​

They DO have a correctly populated database of ALL clients that were once connected to the network. What they simply have to do is make an assumption and simply implement a timer where once a device has been detected as "active/online", it will remain in the "active/online" list for the next XX hours.

Is it really that crucial to remove a devices online/active status ASAP????

---

Of course since this is the trendmicro section of the code, we have no ability to create simple fixes like the on above ....

A lot of the trendmicro code can use improvements / simple fixes across the board. I don't think they care since it really is a MINOR fix.

---

Edit: It does not go by active connections. It detects currently connected devices by using the source data provided by arp.

Arp correctly returns current connected devices but apparently these results parsed either incorrectly or very slowly.