[384.8_Alpha - builds] Testing all variants.

[SMS786]

Just tried connecting to my OpenVPN server on RT-AC68U_384.8_alpha1-g9ac9c80d7 but unable to do so. Client just hangs during the connection process, tried different devices to make sure. Hangs during the following process:

Wed Oct 24 16:26:39 2018 UDP link remote: [AF_INET] xxx.xxx.xxx:xxxx

Will check logs for more details and report back upon returning home. The OVPN server worked fine on the previous alpha.

 

[D_Day]

Uptime 1 day 7 hours here on my vanilla setup. I’ve been testing WiFi speeds and they’ve been very consistent. I’m on 400/20. I’m consistently getting the over provisioned speeds of 470+/23 and no disconnects. Very pleased.

Awesome!
My speeds are supposed to be 80/20 on VDSL but I actually get 59/23 and I have to throttle it to keep the bufferbloat down.
It’s all good though

 

[RMerlin]

Im assuming the new (alpha1-g9ac) 384.8 has the fix included from the 384.7_2 correct?

384.8 alpha is built off the master repository. 384.7_2 is a branch off it, with specific fixes taken out of the master and applied to the branch.

 

[Sonyrolfy]

TX and RX is being reversed in the network map/list overview. In the System log /Wireless Log its still RX/TX. Its like and car heater. warm for right cold for left you get used to it 384.8_alpha1-g9ac9c80d7 / RT-AC86U.

 

[skeal]

Just loaded the new alpha 1. So far so good. Another solid release Eric!!

 

[D_Day]

2 days 5 hours and 17 mins on the latest alpha 1 and no issues other than the browser problem.
I’ve had no dropouts and no speed issues at all.
It very stable for my setup
Great work!!

 

[TonyK132]

Neither of these two files you are trying to use have ever existed in any firmware version. Not sure what you are trying to do here, nvram values can only be manipulated through the nvram userspace tool.

Yes I know. But there was a post at one time that demonstrated how to retrieve the dhcp_staticlist into a file, then after a reset to factory defaults and loading new firmware, to put that file into /jffs/configs/ and upon a reboot the firmware would read that file and load the lists. This is also possible to do with the vpn_client1_clientlist. That sequence worked in 380.70 but is not working in 384.8alpha1. I actually do not know if it has worked in any 384 version. But there are other techniques for using those files, so I may manually do those instead. Or I might also do a script to automate.

 

[Netbug]

dirty upgrade from 384.7_beta3 to 384.8_alpha1-g9ac9c80d7 on my 86u no issues so far

Thanks Merlin!

 

[RMerlin]

Yes I know. But there was a post at one time that demonstrated how to retrieve the dhcp_staticlist into a file, then after a reset to factory defaults and loading new firmware, to put that file into /jffs/configs/ and upon a reboot the firmware would read that file and load the lists. This is also possible to do with the vpn_client1_clientlist. That sequence worked in 380.70 but is not working in 384.8alpha1. I actually do not know if it has worked in any 384 version. But there are other techniques for using those files, so I may manually do those instead. Or I might also do a script to automate.

These instructions were incorrect, or you missed a step, as the firmware will not use either of these two files. It definitely didn't do anything on 380.70 either.

 

[Martineau]

Yes I know. But there was a post at one time that demonstrated how to retrieve the dhcp_staticlist into a file, then after a reset to factory defaults and loading new firmware, to put that file into /jffs/configs/ and upon a reboot the firmware would read that file and load the lists. This is also possible to do with the vpn_client1_clientlist. That sequence worked in 380.70 but is not working in 384.8alpha1. I actually do not know if it has worked in any 384 version. But there are other techniques for using those files, so I may manually do those instead. Or I might also do a script to automate.

The technique proposed/used by @schmerg no longer uses the GUI generated NVRAM variable, instead he manually defines the appropriate DHCP reserved IPs in '/jffs/configs/dnsmasq.conf.add' which is read automatically by dnsmasq when it starts.
So if after your migration you did not restore dnsmsasq.conf.add containing your DHCP reservations, then that would explain your issue.

NOTE: There is a difference between v380.70 and v384.xx in how the entries are physically managed on-disk, but this should not be an issue unless you have a script that explicitly references the 'missing' file.

Can't add Static DHCP entry any more - Merlin 382.1/RT-AC86U

Where does Merlin store hostnames/reserved DHCP IP list?

 

[Sanna1967]

2 days uptime on my AC86 ,and no problemo with wifi drop or speed on both band.

 

[TonyK132]

The technique proposed/used by @schmerg no longer uses the GUI generated NVRAM variable, instead he manually defines the appropriate DHCP reserved IPs in '/jffs/configs/dnsmasq.conf.add' which is read automatically by dnsmasq when it starts.
So if after your migration you did not restore dnsmsasq.conf.add containing your DHCP reservations, then that would explain your issue.

NOTE: There is a difference between v380.70 and v384.xx in how the entries are physically managed on-disk, but this should not be an issue unless you have a script that explicitly references the 'missing' file.

Can't add Static DHCP entry any more - Merlin 382.1/RT-AC86U

Where does Merlin store hostnames/reserved DHCP IP list?

Thanks to both Merlin and Martineau for your comments. Maybe someday, in this or another life, I will find the post that I successfully followed in 380.70 to save and restore the dhcp_staticlist values into the /configs/ sub-dir. But for now, plan B is to just do the appropriate nvram set commands to set the dhcp_staticlist and vpn_client1_clientlist variables from files. I created a small script to do the whole procedure. Worked great.

Now on to the next problem. I had a problem in 380.70 where an icon file was created in the /jffs/usericon/ dir that would continually increase in size until it filled up all of memory. When I posted that problem, I was told that all I had to do was reset to factory defaults, and reconfigure all again, and the problem would go away. Well, fast forward to 384.8_alpha1. In a brand new 86U, I did a reset before loading alpha1, then loaded alpha1, then rebooted a number of times, but now still have the same problem. In that same dir after a reboot, I get an ico file that gets created, and keeps increasing in size. I can manually delete it. And I suppose I could create a cron job to delete it after a reboot. But why is there this problem? Is there something in my config or network or router firmware that could be creating an ico file in that dir, and keep adding to it? If it matters, I use WinSCP as my tool to log into the router.

I found this problem when I tried to save a file in jffs but got a popup that said I had no room to save anything. After digging around I found this ico file. Even now, after I deleted the ico file, when I try to rename a file or save one in jffs, I still get that popup. In Linux land, do I need to flush or clear out a deleted folder somewhere in order to free the space of the deleted ico file?

 

[loveleeyoungae]

Now on to the next problem. I had a problem in 380.70 where an icon file was created in the /jffs/usericon/ dir that would continually increase in size until it filled up all of memory. ?

Remember your post. After reading it, I opened WinSCP to check my jffs folder right away Regarding the jffs partition and file system on these Linux-embedded routers, I think there might be some kind of hardware issue with your router nand flash. I read another post here in which the poster was so frustrated with his router because of this reason: Though the router was working normally, he couldn't enable or use jffs (dont remeber exactly). He tried everything, resetting to factory defaults, reflashing numerous times, and jffs could never be used.

 

[amigohd]

AC86U with 348.8 Alpha: AIProtection signatures fail to update since alpha:

2.088 Updated : 2018/09/18 20:50
"Signature update failed"

anyone have the same problem? any solution?
worked with the latest stable.

 

[Gingernut]

AC86U with 348.8 Alpha: AIProtection signatures fail to update since alpha:

2.088 Updated : 2018/09/18 20:50
"Signature update failed"

anyone have the same problem? any solution?
worked with the latest stable.

No such error here:

Product ID   RT-AC86U
Signature version  2.094  Updated : 2018/10/11 17:38
Signature is up to date

 

[tyreman]

okay here so far
thank you

 

[D_Day]

AC86U with 348.8 Alpha: AIProtection signatures fail to update since alpha:

2.088 Updated : 2018/09/18 20:50
"Signature update failed"

anyone have the same problem? any solution?
worked with the latest stable.

2.094 on my ac68u.

Alpha 1 has been running on my system for 5 days without missing a beat

 

[Blacklistedcard]

2.094 on my ac68u.

Alpha 1 has been running on my system for 5 days without missing a beat

Me too...
Product ID RT-AC86U
Signature version
2.094 Updated : 2018/10/28 05:57



New firmware notification Click here to configure settings.
Firmware Version
384.8_alpha1-g9ac9c80d7

 

[GHammer]

@RMerlin
I experience a kernel call trace due to a formatting error when saving/loading iptables -mangle statements.
Full info is in this thread:
https://www.snbforums.com/threads/h...-entries-ac86u-384-8-alpha.49580/#post-440456

 

[hervon]

Signature version was not updating either @ 2.092. Update check stayed forever @ 'Signature is updating'. Solution was to turn off/on AiProtection. Hope that helps.