Code:#!/bin/sh rm /etc/zebra.conf service restart_quagga
this workaround does not work.
Code:#!/bin/sh rm /etc/zebra.conf service restart_quagga
No. It will only remove the unused variables from nvram, all key and certs are now stored in the JFFS partition.
make sure you have downloaded right file, not fore-ac68u.Can't upgrade my AC86U to 384.10 from 384.9, it keeps through "firmware flashing unsuccessful"; I tried Chrome and IE, I tried (re)downloading through multiple SF mirrors, I even tried unzipping it through Windows 10's built-in ZIP utility and through 7-Zip.
All failed; what could be happening here?
It's been the correct file every time I tried; still, no dice.make sure you have downloaded right file, not fore-ac68u.
Remove ev usb and reboot and try again and you load this file?It's been the correct file every time I tried; still, no dice.
this workaround does not work.
Yes... I was using the *.w file.Remove ev usb and reboot and try again and you load this file?
===>>> RT-AC86U_384.10_0_cferom_ubi.w
Depending on what is running in the background and what USB device(s) are mounted, sometimes it is necessary to remove the drive in order to free up enough RAM to complete the upgrade.Yes... I was using the *.w file.
However, removing my Diversion/Skynet USB drive did the trick; I was able to upgrade after that.
See if the tips on this post help.I updated on beta 3 few days ago and today updated to release it it is so unstable for me once I connect to the VPN and start doing noticable transfers.
Mar 25 18:42:27 rc_service: ntp 531:notify_rc restart_diskmon
Mar 25 18:42:27 rc_service: waitting "start_firewall" via udhcpc ...
Mar 25 18:42:27 kernel: nf_conntrack_rtsp v0.6.21 loading
Mar 25 18:42:27 kernel: nf_nat_rtsp v0.6.21 loading
Mar 25 18:42:28 rc_service: udhcpc 510:notify_rc start_upnp
Mar 25 18:42:28 rc_service: waitting "stop_upnp" via udhcpc ...
Mar 25 18:42:28 disk_monitor: Finish
Mar 25 18:42:29 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Mar 25 18:42:30 miniupnpd[685]: HTTP listening on port 40590
Mar 25 18:42:30 miniupnpd[685]: Listening for NAT-PMP/PCP traffic on port 5351
Mar 25 18:42:30 disk_monitor: be idle
Mar 25 18:42:30 dhcp_client: bound 73.231.231.189 via 73.231.230.1 during 180113 seconds.
Mar 25 18:42:31 WLCEVENTD: eth1: Assoc SO:ME:MA:C_:__:__
Mar 25 18:42:39 WLCEVENTD: eth2: Assoc SO:ME:MA:C_:__:__
<snip>
RMerlin said: ↑
In newer routers, if you experience wireless stability issues then it's recommended that you disable the following options:
- MU-MIMO (some hardware revisions have non-functional/unreliable implementations)
- Airtime Fairness (causes connectivity issues for various devices, including wireless printers)
- Universal Beamforming (non-standard, might cause compatibility issues with some clients)
If you have issues connecting your OpenVPN client, make sure you have up-to-date certificates. Older SHA1-signed certificates are no longer accepted by OpenSSl 1.1.1.
I think he is referring to the CA-Certificate from the VPN provider.Can anyone point me in the right direction regarding updating said certificates? I exported the updated ovpn file from the admin GUI and on my windows client 2.4.7 (which includes OpenSSL 1.1.1) my connection still shows that it's utilizing OpenSSL 1.1.0.
Hi,Notes:
- This release resolved the issue where OpenVPN key/certs might sometimes end up stored in nvram (in addition to their proper jffs location), which would result in a lot of wasted nvram. I have also removed the nvram instances of these nvram values, to save even more nvram. To clean up your router, you can run the following script:
Code:#!/bin/sh echo "Removing unused cert/key from nvram..." for i in 1 2 3 4 5 do nvram unset vpn_crt_client$i\_ca nvram unset vpn_crt_client$i\_extra nvram unset vpn_crt_client$i\_crt nvram unset vpn_crt_client$i\_key nvram unset vpn_crt_client$i\_crl nvram unset vpn_crt_client$i\_static done for i in 1 2 do nvram unset vpn_crt_server$i\_ca nvram unset vpn_crt_server$i\_dh nvram unset vpn_crt_server$i\_ca_key nvram unset vpn_crt_server$i\_extra nvram unset vpn_crt_server$i\_client_crt nvram unset vpn_crt_server$i\_crl nvram unset vpn_crt_server$i\_crt nvram unset vpn_crt_server$i\_key nvram unset vpn_crt_server$i\_static nvram unset vpn_crt_server$i\_client_key done nvram commit echo "done."
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!