What's new

[Thread-1] [ 386.1_Alpha Build(s) ] Testing available build(s)

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

Status
Not open for further replies.
Energy Efficient Ethernet is disabled by default on the new (386) version?
Can some one check if " pwr show " output shows EEE disabled?

I just don't remember if I used a script to make it startup with EEE disabled and where\if I hid it (I used to disable this feature in the past)

Thanks
 
Energy Efficient Ethernet is disabled by default on the new (386) version?
Can some one check if " pwr show " output shows EEE disabled?

I just don't remember if I used a script to make it startup with EEE disabled and where\if I hid it (I used to disable this feature in the past)

Thanks

AX88U

Code:
WIFI Off            Disabled
DISK Off            Disabled
PCI ASPM            Disabled
UBUS DCM            N/A
CPU Off             N/A
CPU Wait            Disabled
CPU Speed           Enabled
XRDP Gate           N/A
NET Down            Disabled
PHY Down            Disabled
PHY EEE             Enabled
PHY APD             Enabled
SF2 DGM             Enabled
DRAM SR             N/A
AVS                 Enabled
 
Energy Efficient Ethernet is disabled by default on the new (386) version?
Can some one check if " pwr show " output shows EEE disabled?

I just don't remember if I used a script to make it startup with EEE disabled and where\if I hid it (I used to disable this feature in the past)

Thanks

AC86U - may be on to something but I never checked this before 386.1alpha and I don't know what is to be expected for each model.

Code:
Power Management Configuration
Functional Block           Status
CPU Wait                   ENABLED
Ethernet Auto Power Down   ENABLED
Energy Efficient Ethernet  DISABLED
Switch Deep Green Mode     ENABLED (status: Deactivated)
 
rt-ax56u
Code:
WIFI Off            Disabled
DISK Off            Disabled
PCI ASPM            N/A
UBUS DCM            Enabled
CPU Off             N/A
CPU Wait            Enabled
CPU Speed           N/A
XRDP Gate           N/A
NET Down            Disabled
PHY Down            Disabled
PHY EEE             Enabled
PHY APD             Enabled
SF2 DGM             N/A
DRAM SR             Disabled
AVS                 Enabled
WLAN Down           N/A
PMD Off             N/A
 
It's a flowcache problem that's been there for me since the very first RC2 beta on the RT-AX88U. No idea what triggers it since it's related to the closed source hardware acceleration, and I haven't had time to test things out with the stock firmware. Only workaround for now is to disable flowcache:

Code:
fc disable
RMerlin,

Thank you for 386.1 Alpha2 :)

Feedback: while “fc disable” stops the repeated “kernel: protocol 0800 is buggy, dev eth7” message, I discovered that my SpeedTest App on my MacBookPro connected via CAT 6 Ethernet Cable to either AiMesh Router (RT-AX88U) or AiMesh Node (RT-AC86U) degraded to around 350 mbps where I normally gets around 900++ mbps.
When I do “fc enable” I get back my speed; I will just live with the repeated messages.
 
Observation:
Bug: network map --> view list --> interface --> guest network (I setup Guest Network Index 1 on 5GHz band)
Incorrect Guest WiFi IP ADDRESS ASSIGNMENT displayed for devices whose MAC Address that are manually defined in my DHCP List.
  • Displayed incorrectly as 192.168.50.101 which is in my Primary subnet of my Home Network
  • Where It is actually 192.168.102.88 in a different subnet, I found out with a Network Analyser App
PS: The problem exist in RC2-6 (and earlier) and was fixed in RC2-7 (9.0.0.4_386_40577-g3427c43). Found in Merlin 386.1 Alpha 2.
Oops,

I take back my observation. I have retried this morning and discovered the the Guest WiFi IP address assignment for my iPhoneXsMax is displayed correctly even when my MAC Address is in my DHCP list. The only change that happened is I updated my iOS from 14.1 to 14.2. Sorry!
 
RMerlin,

Thank you for 386.1 Alpha2 :)

Feedback: while “fc disable” stops the repeated “kernel: protocol 0800 is buggy, dev eth7” message, I discovered that my SpeedTest App on my MacBookPro connected via CAT 6 Ethernet Cable to either AiMesh Router (RT-AX88U) or AiMesh Node (RT-AC86U) degraded to around 350 mbps where I normally gets around 900++ mbps.
When I do “fc enable” I get back my speed; I will just live with the repeated messages.

Which is to be expected, fc = Flow Cache.
 
One interesting thing to note, Google Home devices broadcast MDNS messages... quite a lot actually. This noise can cause other devices on the network to have issues (aka Belkin Wemo devices).

When Google Homes are on a Shared (slot 1) Guest Wifi, even with Intranet access disabled, those broadcast messages are leaked to the entire intranet network. Moving to a slot 2 guest wifi still seems to allow that, but using @Jack Yaz YazFi on that slot 2 guest network stops that from happens. YazFi's IP rules are more broad.

Does anyone know how YazFi interacts with the new Slot 1 GuestNet behaviour? I haven't had the time to try it and see, curious what it does? Can you change the IP range away from 192.168.101.x? Can you override the DNS?

Also, one other quick observation to share, if you are using unbound_manager and use the disable dnsmasq DNS feature, you need to add a new dhcp-option=br2,6,<dnsip> to your dnsmasq.conf.add file so that it gets a DNS set. Otherwise all clients on that network will not be able to access a DNS unless manually set.
 
Thanks everyone for 386 version, really looking forward for final version!!

Hello,

Upgraded to alpha2 my 2 x AX88U (router and AiMesh node) with full factory reset.
Appears to be running smoothly, I will observe it for a few days.

A few notes for your consideration.

System Log
Start of system log looks very strange, @RMerlin - does it look normal?
Code:
May 5 06:05:13 syslogd started: BusyBox v1.25.1
May 5 06:05:13 kernel: klogd started: BusyBox v1.25.1 (2020-11-02 18:11:38 EST)
May 5 06:05:13 crashlog:
May 5 06:05:13 kernel: Booting Linux on physical CPU 0x0
May 5 06:05:13 kernel: Linux version 4.1.51 (merlin@ubuntu-dev) (gcc version 5.5.0 (Buildroot 2017.11.1) ) #2 SMP PREEMPT Mon Nov 2 18:28:05 EST 2020
May 5 06:05:13 crashlog:
May 5 06:05:13 kernel: CPU: AArch64 Processor [420f1000] revision 0
May 5 06:05:13 kernel: Detected VIPT I-cache on CPU0
May 5 06:05:13 crashlog:
May 5 06:05:13 kernel: alternatives: enabling workaround for ARM erratum 845719
May 5 06:05:13 crashlog:
May 5 06:05:13 crashlog

Ookla CLI speed
This is an interesting one. I have 910/110 nominal speed and on Asus Merlin 384.19 it was showing that when plugged to routher via 1GB cable, while on the router itself spdMerlin was showing approx. half of it due to utilisation of single CPU only. Now spdMerlin and WebUI speed tests show 820-840/110 and strangely my PC connected to the main router via ethernet cable is now shoing 820-840/110 too. So great it is all consistent, not so great than 10% of speed disappears somewhere on the router. Other people observed same slow down behaviour on AX88U earlier - see ASUSWRT 386 RC2 thread for all release candidates. Sounds as a Asus bug, @ASUSWRT_2020
UPDATE: Sadly Ookla CLI runs on speeds went back down to 340-380/111, back to maxing out one CPU - both WebUI or spdMerlin, it shows something is odd with Asus infra rather than Ookla test itself. Even more sad that speed test on my PC connected via ethernet cable to AX88U remain low as 820-840. Not going back to 384.19 just for to increase it back to 910.
UPDATE2: Managed to find out what causing Ookla timings to be halfed on AX88U.
It is TrendMicro Traffic Analyser. Signing or withdrawing privacy EULA flicks the behaviour. Sounds as a feature that's here to stay for a while.
UPDATE3: Managed to solve 10% speed dropdown - it required two things:
- resetting my BT FTTH modem, speed went up immediately, do not know how that's relevant to router upgrade
- switching to a different Ookla server for tests (do not know why the one I have been always been using). Now getting consistent speeds on PC, Ookla WebUI and spdMerlin 900-915/111-112Mbs

WAN default settings [found some earlier Merlin response on another thread that this normal]
I observed that default WAN settings has changed, specifically
Special Requirement from ISP / Enable VPN + DHCP Connection was flicked to Yes after factory reset.
I flicked it back No, but unsure what should be setting for BT really. Comments?

Strange behaviour on first startup
I observed a strange behaviour after first start (after factory reseet and setting up WAN). Basically everything appeared to be running - WAN/LAN connecting, nslookups/pings from my PC, even ookla cli test.
However any browsers were unable to load any websites (not DNS message, some disconnects). Not something I have seen before. Tried on my PC: reboot, ipconfig/flushdns, ipconfig/renew. Nothing helped.
Only full router reboot helped, which I was planning to do anyway.

AiMesh client list bug
@ASUSWRT_2020
There is a bug with wirless clients that disconected with AiMesh node (as they are switched off). They appear on Network Map / View list as wired strangely.

Overall happy with my AX88U AiMesh 386.1-alpha2 and keeping it until official release.
 
Any other Astrill VPN Router applet users having trouble with 386.1 alpha2?

Up until this morning, it was fine. Applet v2.9.33 was working fine. But then, in the middle of the night or this morning, it auto-updated to v2.9.34 and now I get the following log entry:

Wed Nov 11 01:03:46 2020 ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
Wed Nov 11 01:03:46 2020 Exiting due to fatal error

I will reformat JFFS and reinstall it. Maybe I can even ask Astrill for a link to v2.9.33

UPDATE:

Yes, definitely toast. I'm also playing with ASUS's Instant Guard v1.0.9 app. Not sure whether that app might have changed something on the router that now prevents the Astrill TUN device from loading.
 
Last edited:
One interesting thing to note, Google Home devices broadcast MDNS messages... quite a lot actually. This noise can cause other devices on the network to have issues (aka Belkin Wemo devices).

When Google Homes are on a Shared (slot 1) Guest Wifi, even with Intranet access disabled, those broadcast messages are leaked to the entire intranet network. Moving to a slot 2 guest wifi still seems to allow that, but using @Jack Yaz YazFi on that slot 2 guest network stops that from happens. YazFi's IP rules are more broad.

Does anyone know how YazFi interacts with the new Slot 1 GuestNet behaviour? I haven't had the time to try it and see, curious what it does? Can you change the IP range away from 192.168.101.x? Can you override the DNS?

Also, one other quick observation to share, if you are using unbound_manager and use the disable dnsmasq DNS feature, you need to add a new dhcp-option=br2,6,<dnsip> to your dnsmasq.conf.add file so that it gets a DNS set. Otherwise all clients on that network will not be able to access a DNS unless manually set.
Yea I noticed DNSmasq requires alittle bit more TLC when it comes to these new dnsmasq parameters. One good positive, @thelonelycoder Diversion seems to operate abit more stable in conjunction with the alpha so far. @thelonelycoder has a lot to look forward to once this release is finalized. Also, unbound seems to be abit more stable in conjunction with dnsmasq .(when not disabling dnsmasq dns feature.)
 
Yea I noticed DNSmasq requires alittle bit more TLC when it comes to these new dnsmasq parameters. One good positive, @thelonelycoder Diversion seems to operate abit more stable in conjunction with the alpha so far. @thelonelycoder has a lot to look forward to once this release is finalized. Also, unbound seems to be abit more stable in conjunction with dnsmasq .(when not disabling dnsmasq dns feature.)
Just curious...in what manner are you seeing better stability in both of the above add-ons? I wasn't aware of any particular instability in either one on previous 384 series firmware.
 
Just curious...in what manner are you seeing better stability in both of the above add-ons? I wasn't aware of any particular instability in either one on previous 384 series firmware.
Yea it was not to supply the existence of instability, but more to imply better performance. I do not experience any crashes. I think it has to do more with the restructuring of Aimesh. Because of this restructuring, it appears operating unbound and diversion can be done in a more stable manner than it could previously in the same conditions that I operate.
 
Which is to be expected, fc = Flow Cache.

I only got the 0800 protocol is buggy message when a guest network was active. ac86u. Spammed the whole log. was not related to aimesh or any other router features enabled except guest wifi. But the same ssid name and password with same client devices as the main internal network did not produce the error. I know I told you this already on IRC and you told me it was alpha and to not bother you. But I wanted to go on record here since I didn't see it mentioned related to guest network. :)
 
Last edited:
Another thing I found today. I had typically disabled Spanning Tree Protocol (STP) on the LAN manu. Cannot recall exactly, but it was causing some slowdowns or something.

Well, with 386 and AiMesh 2.0, I was having some odd connection timeouts and other issues on my RaspberryPi running Home Assistant. Some Wemo plugs going "unavailable" constantly and my internet test failing to ping properly. A few hours ago I tried putting STP back on (it is on by default) and now no issues for the past few hours.

Just sharing in case others see similar issues.
 
I only got the 0800 protocol is buggy message when a guest network was active. ac86u. Spammed the whole log. was not related to aimesh or any other router features enabled except guest wifi. But the same ssid name and password with same client devices as the main internal network did not produce the error. I know I told you this already on IRC and you told me it was alpha and to not bother you. But I wanted to go on record here since I didn't see it mentioned related to guest network. :)
cooloutac,
Thank you, I remove my WiFi Guest Network, the 0800 protocol message no more appear in the log now. I do not operationaly use the WiFi Guest Network, I setup more for the purpose of testing the FW. Thanks.
 
RT-AC88U 386.1_alpha-2

After flashing, my system log is getting these messages every 30 seconds
Code:
rc_service: watchdog 445:notify_rc start_cfgsync
custom_script: Running /jffs/scripts/service-event (args: start cfgsync)

Everything else looks okay.
 
Another thing I found today. I had typically disabled Spanning Tree Protocol (STP) on the LAN manu. Cannot recall exactly, but it was causing some slowdowns or something.

Well, with 386 and AiMesh 2.0, I was having some odd connection timeouts and other issues on my RaspberryPi running Home Assistant. Some Wemo plugs going "unavailable" constantly and my internet test failing to ping properly. A few hours ago I tried putting STP back on (it is on by default) and now no issues for the past few hours.

Just sharing in case others see similar issues.

This makes sense, STP=Enable : https://en.wikipedia.org/wiki/Spanning_Tree_Protocol
If it wasn't the default, every switch would have to be managed, and AiMesh would need a LOT more config/oversight
 
Status
Not open for further replies.

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