[384.18_Alpha Builds] Testing all variants

[MarkyPancake]

Here is the changelog, linked in post #2.
https://github.com/RMerl/asuswrt-merlin.ng/blob/master/Changelog-NG.txt

This probably happens all the time, but I don't usually pore over release notes. Just took a look and noticed this reference for the 86U:

Merged SDK + binary blobs from 384_81846 for RT-AC86U

Does that version number relate to the stock firmware. From what I can see a 384.81846 version was never released for the 86U and it went 384.81369 to 384.81858. So, I was just curious how this translates to the Merlin build.

 

[QuikSilver]

This probably happens all the time, but I don't usually pore over release notes. Just took a look and noticed this reference for the 86U:



Does that version number relate to the stock firmware. From what I can see a 384.81846 version was never released for the 86U and it went 384.81369 to 384.81858. So, I was just curious how this translates to the Merlin build.

This help?
https://www.snbforums.com/threads/384-18_alpha-builds-testing-all-variants.63954/page-6#post-587030

 

[Butterfly Bones]

This probably happens all the time, but I don't usually pore over release notes. Just took a look and noticed this reference for the 86U:



Does that version number relate to the stock firmware. From what I can see a 384.81846 version was never released for the 86U and it went 384.81369 to 384.81858. So, I was just curious how this translates to the Merlin build.

Keep in mind RMerlin uses the GPL releases, not the public releases as hinted by @QuikSilver in the link above.

 

[Gar]

should work with: ssh userid@routeraddress
next would be password.

That was it, all A-OK now. Thanks!

Was use to using my 56u with the 374 fork.

 

[jpthsd]

what is the ETA for 384.18? I seem kinda stable on 384.17 (AC86U AiMesh Router, AC68 AiMesh Node)...can't get any better!

 

[Kingp1n]

what is the ETA for 384.18? I seem kinda stable on 384.17 (AC86U AiMesh Router, AC68 AiMesh Node)...can't get any better!

It can be a few more weeks...a beta will follow after...patience is key!

 

[Sachb]

With due respect, @RMerlin , would it be possible for you to make a firmware which unlocks channel 149-165 or is it hard coded and not possible?

I'm using DFS channel and I'm finding it annoying to wait for 1 min everytime the router reboots for the 5Ghz to show up on my devices.

It's really strange for Asus to lock channels 149-165, in my region.

D-link doesn'nt follow the same regulation which I purchased locally in the same region. My D-link DIR 882 router has channels 149-165.

Sent from my LM-G710 using Tapatalk

 

[octopus]

With due respect, @RMerlin ,
I'm using DFS channel and I'm finding it annoying to wait for 1 min everytime the router reboots for the 5Ghz to show up on my devices.

1 minute wait when 5Ghz starting is for scanning radar activity in your environment. I think wifi is closed source code. You have to ask asus on that.

 

[Smokey613]

I took the plunge and updated both the 86U and 1900P. So far, so good.

 

[Sander_H]

Running Merlin 384.18_alpha1 on an RT-86U as AI MESH router with 2 AC68U AI MESH nodes.
No major issues except I get 100's of these per minute:

Jun 9 14:01:21 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 1C:87:2C:xx:xx:71, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Jun 9 14:01:21 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth5: Auth 1C:87:2C:xx:xx:71, status: Successful (0)
Jun 9 14:01:21 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth5: Assoc 1C:87:2C:xx:xx:71, status: Successful (0)
Jun 9 14:01:29 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 1C:87:2C:xx:xx:71, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS

These seem to originate from the 2.4Ghz band, where I can see 1C:87:2C:xx:xx:71 connecting briefly. Not sure why one of the AI MESH nodes is trying to connect via 2.4Ghz - I always thought the back-end was 5Ghz only.

br0 Link encap:Ethernet HWaddr 1C:87:xx:xx:xx:70
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:8953164 errors:0 dropped:0 overruns:0 frame:0
TX packets:417972 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1949691838 (1.8 GiB) TX bytes:62672245 (59.7 MiB)

dpsta Link encap:Ethernet HWaddr 1C:87:xx:xx:xx::70
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:17686694 errors:0 dropped:0 overruns:0 frame:25785061
TX packets:6739304 errors:50218 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1401235369 (1.3 GiB) TX bytes:3160459108 (2.9 GiB)

eth0 Link encap:Ethernet HWaddr 1C:87:xx:xx:xx::70
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3152532 errors:0 dropped:0 overruns:0 frame:0
TX packets:12687594 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:698780335 (666.4 MiB) TX bytes:2522414545 (2.3 GiB)
Interrupt:179 Base address:0x4000

eth1 Link encap:Ethernet HWaddr 1C:87:xx:xx:xx::71
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:7201957 errors:0 dropped:0 overruns:0 frame:20416856
TX packets:3278252 errors:49964 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3968211044 (3.6 GiB) TX bytes:2402589879 (2.2 GiB)
Interrupt:163

eth2 Link encap:Ethernet HWaddr 1C:87:xx:xx:xx:74
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:10484737 errors:0 dropped:0 overruns:0 frame:5368205
TX packets:3461052 errors:254 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1727991621 (1.6 GiB) TX bytes:757869229 (722.7 MiB)
Interrupt:169

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:3517792 errors:0 dropped:0 overruns:0 frame:0
TX packets:3517792 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:572931197 (546.3 MiB) TX bytes:572931197 (546.3 MiB)

lo:0 Link encap:Local Loopback
inet addr:127.0.1.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1

vlan1 Link encap:Ethernet HWaddr 1C:87:xx:xx:xx:70
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:3152531 errors:0 dropped:0 overruns:0 frame:0
TX packets:12687594 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:682957930 (651.3 MiB) TX bytes:11083621509 (10.3 GiB)

vlan2 Link encap:Ethernet HWaddr 1C:87:xx:xx:xx:70
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wl0.1 Link encap:Ethernet HWaddr 1C:87:xx:xx:xx:71
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:4126998 errors:0 dropped:0 overruns:0 frame:20416856
TX packets:9645666 errors:517617 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2365267909 (2.2 GiB) TX bytes:532693072 (508.0 MiB)

wl1.1 Link encap:Ethernet HWaddr 1C:87:xx:xx:xx:74
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:501 errors:0 dropped:0 overruns:0 frame:5368205
TX packets:4731533 errors:553 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:72264 (70.5 KiB) TX bytes:1507897266 (1.4 GiB)

 

[Wadadli]

On the 5GHz band, it looks like everyone else is in the 100-165 channel range. Absolutely nobody in the channel 36 to 64 range. I suspect everyone else is in auto mode and it puts them in that range by default? I assume that channel 36 to 64 has no disadvantages over 100-165 channels, correct? I'd be the only one close by in that range which would be very good. Why is there such a gap in channels from 64 to 100?

First, only use channels 36-48 or 149-165. In North America the lower 5Ghz channels are limited to 200 mW output. The higher channels are allowed 900 mW output.

 

[MarkyPancake]

With due respect, @RMerlin , would it be possible for you to make a firmware which unlocks channel 149-165 or is it hard coded and not possible?

The router's channels are governed by the radio laws of the country where that router is being sold. Merlin wouldn't change this even if he could, as why would he want to risk breaking the law and the consequences that go along with it.

 

[Sachb]

The router's channels are governed by the radio laws of where that router is being sold. Merlin wouldn't change this even if he could, as why would he want to risk breaking the law and the consequences that go along with it.

I don't know if this law applies to Asus router only, as I have a D-link DIR-882 that has access to channels 149-165.

Moreover my older 2016 Netgear R7800 lets me choose any wireless region I want to.

So, I don't know what's up with these Asus routers having 149-161 locked.

So either Asus is screwing it's customers deliberately or it might be under the pressure of the governed body.

Sent from my LM-G710 using Tapatalk

 

[RMerlin]

So either Asus is screwing it's customers deliberately or it might be under the pressure of the governed body.

Or, you bought a router manufactured for a different region, hence the difference in available channels.

 

[maxbraketorque]

First, only use channels 36-48 or 149-165. In North America the lower 5Ghz channels are limited to 200 mW output. The higher channels are allowed 900 mW output.

The conducted power limitation of 200 mW for the lower 5 GHz wifi channels was changed in 2014. Its now the same as the upper channel range, and both are 1 W for a wifi router. Stations (phones, computer, IOT) are limited to 250 mW.

https://transition.fcc.gov/bureaus/.../51-New-Rules-for-UNII-Bands,-Oct-2014-TN.pdf

 

[ugandy]

The conducted power limitation of 200 mW for the lower 5 GHz wifi channels was changed in 2014. Its now the same as the upper channel range, and both are 1 W for a wifi router. Stations (phones, computer, IOT) are limited to 250 mW.

https://transition.fcc.gov/bureaus/.../51-New-Rules-for-UNII-Bands,-Oct-2014-TN.pdf

is this implemented in recent models from Asus?
thanks

 

[juched]

The conducted power limitation of 200 mW for the lower 5 GHz wifi channels was changed in 2014. Its now the same as the upper channel range, and both are 1 W for a wifi router. Stations (phones, computer, IOT) are limited to 250 mW.

https://transition.fcc.gov/bureaus/.../51-New-Rules-for-UNII-Bands,-Oct-2014-TN.pdf

Yes, I read this as well, but I noticed a huge difference in signal strength on my RT-AX88U between 36 and 149. 149 is much stronger.

 

[Deleted member 22229]

is this implemented in recent models from Asus?
thanks

Yes i know for sure since 2015 this has been implemented in the US. Older models however remain as they were with less power on the lower 5 G channels.

 

[madfusker]

I did some testing here with my AX88U and didn't see a difference. The router is 2 stories below me in the test, so I was -82dBm +/- 2 for the upper and lower channels no matter what I set it on.

I would like to know if anyone has ever been successful with Smart connect though. If it worked it would be perfect in my case. The upper part of my house is barely strong enough for 5GHz, so I need 2GHz when sleeping, but would be nice to be on 5GHz the rest of the time when not in the upper level. I tried this about a year ago and has nothing but problems with it trying to be "smart".

 

[Sachb]

Or, you bought a router manufactured for a different region, hence the difference in available channels.

Maybe, they're distributing the EU version to us now.

My previous Asus routers, had channels 149-161.

I'm not sure if Netgear's newer routers have the same restrictions.

Luckily, It has DFS channels, so that's fine for now.

Sent from my LM-G710 using Tapatalk