What's new

Asuswrt-Merlin 374.39 is out

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

Hi RMerlin,

I don't want to set it to yes... I found an error in the default smb.conf file: (here's a snapshot)

<....
max connections = 5
socket options = TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=65536 SO_SNDBUF=65536
obey pam restrictions = no
use spne go = no
client use spnego = no
disable spoolss = yes
host msdfs = no
strict allocate = No
bind interfaces only = yes
interfaces = lo br0
....>

The line in bold is "invalid" which is causing issue... Once removed and samba restarted my issue are gone... But when rebooting, the line is back by default ... I think it's a bug or something put this in the config file by default... (typo?)

Looks like a typo then. There shouldn't be a space indeed in there (it's "use spnego"). Maybe you are affected because it defaults to yes rather than being properly set to "no" due to the typo. I'll take a look.
 
Looks like a typo then. There shouldn't be a space indeed in there (it's "use spnego"). Maybe you are affected because it defaults to yes rather than being properly set to "no" due to the typo. I'll take a look.

I think this line can be removed ... The correct line is supposed to be:

client use spnego = no

Which is the next in the conf file ... What do you think ...
 
2.4GHz Drops with 3.0.0.4.374.39_0-em on RT-N66U

Since updating from firmware 3.0.0.4.270.26b to 3.0.0.4.374.39_0-em on my RT-N66U (followed by a reset to factory defaults, and manually re-entering all settings) three weeks ago, I have now lost my main 2.4GHz private network connection three times - affecting all devices connected to that 2.4GHz wireless network.

To clarify, I have a main 2.4GHz private network with a hidden SSID (WPA2), a main 5GHz private network with a hidden SSID (WPA2), and a 'public' 2.4GHz guest network with a broadcast SSID (WPA2). The keys for all three are different. I do it this way not so much for security (so please don't comment on hidden SSIDs), but for ease of use. My two main private networks are used by all my personal devices and those of family members living with me. This way the public network is the only one visible for my guests to connect to, and they don't even try to connect to either main wireless network. For that, my system works quite well.

When I lose the main 2.4GHz private network (and everyone using it starts complaining at once), the public 2.4GHz guest network continues to function normally, maintaining existing connections and accepting new connections. Any attempt to connect to the main 2.4GHz private network at this time fails. This network cannot be found at all by any of the devices (computers, tablets, phones, wireless bridges, etc.) configured to use it. The only solution I have found is to reboot the router, which then restores the main 2.4GHz private network and all these devices can once again connect to it.

When this happened again today at 10:15am, I checked the system log and there were no entries later than 2:56am. Nothing was logged that would indicate why the main 2.4GHz private network is becoming unreachable. I am at a loss to explain why this is happening. It never manifested with firmware 3.0.0.4.270.26b or earlier.

I want to be clear that all devices connecting to the main 2.4GHz private network are affected by this - not a subset of those devices. So the issue isn't likely to be related in any way to those devices or the drivers they are using. All these devices are also configured to connect to that wireless network regardless of whether or not the SSID is broadcast (which only makes sense, since I'm not broadcasting the SSID). Also, I've never had a similar problem with the 5GHz network, which continues to function normally during these episodes along with the public 2.4GHz guest network.

Any ideas as to what the issue might be - or what I can tweak to fix it? I sure appreciate any assistance anyone can offer. I really don't want to have to drop all the way back to 3.0.0.4.270.26b, as I very much enjoy the additional features and functionality that have been implemented since then.
 
Since updating from firmware 3.0.0.4.270.26b to 3.0.0.4.374.39_0-em on my RT-N66U (followed by a reset to factory defaults, and manually re-entering all settings) three weeks ago, I have now lost my main 2.4GHz private network connection three times - affecting all devices connected to that 2.4GHz wireless network.

To clarify, I have a main 2.4GHz private network with a hidden SSID (WPA2), a main 5GHz private network with a hidden SSID (WPA2), and a 'public' 2.4GHz guest network with a broadcast SSID (WPA2). The keys for all three are different. I do it this way not so much for security (so please don't comment on hidden SSIDs), but for ease of use. My two main private networks are used by all my personal devices and those of family members living with me. This way the public network is the only one visible for my guests to connect to, and they don't even try to connect to either main wireless network. For that, my system works quite well.

When I lose the main 2.4GHz private network (and everyone using it starts complaining at once), the public 2.4GHz guest network continues to function normally, maintaining existing connections and accepting new connections. Any attempt to connect to the main 2.4GHz private network at this time fails. This network cannot be found at all by any of the devices (computers, tablets, phones, wireless bridges, etc.) configured to use it. The only solution I have found is to reboot the router, which then restores the main 2.4GHz private network and all these devices can once again connect to it.

When this happened again today at 10:15am, I checked the system log and there were no entries later than 2:56am. Nothing was logged that would indicate why the main 2.4GHz private network is becoming unreachable. I am at a loss to explain why this is happening. It never manifested with firmware 3.0.0.4.270.26b or earlier.

I want to be clear that all devices connecting to the main 2.4GHz private network are affected by this - not a subset of those devices. So the issue isn't likely to be related in any way to those devices or the drivers they are using. All these devices are also configured to connect to that wireless network regardless of whether or not the SSID is broadcast (which only makes sense, since I'm not broadcasting the SSID). Also, I've never had a similar problem with the 5GHz network, which continues to function normally during these episodes along with the public 2.4GHz guest network.

Any ideas as to what the issue might be - or what I can tweak to fix it? I sure appreciate any assistance anyone can offer. I really don't want to have to drop all the way back to 3.0.0.4.270.26b, as I very much enjoy the additional features and functionality that have been implemented since then.

I've also noticed EM-build will cause connection drops on 2.4 Ghz. I notice it when I initially flash the firmware, and don't configure my normal settings yet.

The 2.4 Ghz settings I use that fixes the problem are:

N-only
uncheck b/g box
Use "20 Mhz"
I use channel 11, but choose a channel that works for you in your environment.
Remove your wireless profiles from all of your devices and then reconnect.

That's it. I can't tell you specifically which step is the one that resolves the issue because I haven't taken the time (or had any interest) to figure it out. But the troubleshooting steps in link below should solve your problem with EM in addition to the ones that I listed above.

http://forums.smallnetbuilder.com/showthread.php?t=12453
 
Last edited:
I've also noticed EM-build will cause connection drops on 2.4 Ghz. I notice it when I initially flash the firmware, and don't configure my normal settings yet.

The 2.4 Ghz settings I use that fixes the problem are:

N-only
uncheck b/g box
Use "20 Mhz"
I use channel 11, but choose a channel that works for you in your environment.
Remove your wireless profiles from all of your devices and then reconnect.

That's it. I can't tell you specifically which step is the one that resolves the issue because I haven't taken the time (or had any interest) to figure it out. But the troubleshooting steps in link below should solve your problem with EM in addition to the ones that I listed above.

http://forums.smallnetbuilder.com/showthread.php?t=12453

I've already done everything you listed, except Use 20MHz. I live in a rural area and have absolutely no interference, so I've always been able to use 40MHz without any problem. However, I did just make the change and will see if it has any affect going forward. I hate to give this option up, but stability and reliability on 2.4GHz certainly trumps that. Thanks.
 
slow gui over https

Hey, just found gui is very slow when trying to use https. Is anyone else having the same issue? It seems to be affecting every page. Plain http works just fine.

Any clue?

Cheers!
William
 
Is there any way to preserve open VPN settings similar to how I can save static dhcp settings from NVRaM ?

also what is the best way to proceed with the upgrade from 38_2-em ?

I am assuming these are the steps to follow based on the last firmware upgrade to 38_2 I did

Code:
1. backup settings ( in case of reverting ) 

2. get all firewall rules and static dhcp settings with these commands
           nvram get vts_rulelist
           nvram get dhcp_staticlist

3. Flash the new build

4. Do a factory reset

5. Do a manual reconfigure all the settings if applicable ( these are mine ):

        a. SSID's and Security
        b. WifI proffesional settings
        c.  DDNs
        d. Open VPN
        e. DHCP
        f. JFFS Scripts

6. re-add static dhcp and firewall rules 
       nvram set vts_rulelist=<output from step 2>
       nvram set dhcp_staticlist=<output from step 2>
       nvram commit
 
Is there any way to preserve open VPN settings similar to how I can save static dhcp settings from NVRaM ?

also what is the best way to proceed with the upgrade from 38_2-em ?

I am assuming these are the steps to follow based on the last firmware upgrade to 38_2 I did

Code:
1. backup settings ( in case of reverting ) 

2. get all firewall rules and static dhcp settings with these commands
           nvram get vts_rulelist
           nvram get dhcp_staticlist

3. Flash the new build

4. Do a factory reset

5. Do a manual reconfigure all the settings if applicable ( these are mine ):

        a. SSID's and Security
        b. WifI proffesional settings
        c.  DDNs
        d. Open VPN
        e. DHCP
        f. JFFS Scripts

6. re-add static dhcp and firewall rules 
       nvram set vts_rulelist=<output from step 2>
       nvram set dhcp_staticlist=<output from step 2>
       nvram commit

This is a script I use to restore the DHCP static list

http://forums.smallnetbuilder.com/showpost.php?p=106371&postcount=12

and I have a similar script for the OpenVPN Server keys etc.

Code:
#!/bin/sh

# EIC Refresh OPENVPN Server 1 keys

logger -t "($(basename $0))" OPENVPN Server 1 keys reset!



# Certificate Authority: CA.CRT
nvram set vpn_crt_server1_ca="-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----"

# Server Certificate: RT-N66U.CRT
vpn_crt_server1_crt="-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----"


# Server Key: RT-N66U.KEY
nvram set vpn_crt_server1_key="-----BEGIN PRIVATE KEY-----
<snip>
-----END PRIVATE KEY-----"


# Diffie hellman Parameter: dh1024.PEM
nvram set vpn_crt_server1_dh="-----BEGIN DH PARAMETERS-----
<snip>
-----END DH PARAMETERS-----"


nvram set vpn_server_cipher="AES-128-CBC"

nvram commit

and another script for generic custom settings - DYNDNS, PPTP server settings etc.

Regards,
 
If you do a complete dump of your nvram settings, and have it sorted alphabetically:

Code:
nvram show | sort > /mnt/sda1/settings.txt

then you can easily pick those settings. They will all start with vpn_server1_ in their name, with a few exception that will be vpn_serverx_ or vpn_server_.
 
Thanks. It's odd that it's happening to some people and not others (like me).

saintdev, ok it finally happened to me again (lost ipv6) after the router was up for a week. I had the debug settings on that you recommended.

looking at the log, this seems to be the relevant part. there are no errors in the cable modem logs. i'm leaving the router in the bad state for now (no ipv6) in case there's something you want to see.

Feb 20 22:23:44 rc_service: dhcp6c-state 1984:notify_rc start_radvd
Feb 20 22:23:44 rc_service: dhcp6c-state 1984:notify_rc start_httpd
Feb 20 22:23:44 rc_service: waitting "start_radvd" via dhcp6c-state ...
Feb 20 22:23:44 radvd[1655]: Exiting, sigterm or sigint received.
Feb 20 22:23:44 radvd[1655]: sending stop adverts
Feb 20 22:23:44 radvd[1655]: removing /var/run/radvd.pid
Feb 20 22:23:44 radvd[1988]: version 1.9.7 started
Feb 20 22:23:45 RT-N66U: start httpd
Feb 20 22:23:49 rc_service: dhcp6c-state 1993:notify_rc start_radvd
Feb 20 22:23:49 rc_service: dhcp6c-state 1993:notify_rc start_httpd
Feb 20 22:23:49 rc_service: waitting "start_radvd" via dhcp6c-state ...
Feb 20 22:23:49 radvd[1991]: Exiting, sigterm or sigint received.
Feb 20 22:23:49 radvd[1991]: sending stop adverts
Feb 20 22:23:49 radvd[1991]: removing /var/run/radvd.pid
Feb 20 22:23:49 radvd[1997]: version 1.9.7 started
Feb 20 22:23:50 RT-N66U: start httpd
 
Forgive my ignorance, what is the difference between the stander 39_0 and the -em version this time around ? I was not able to effectively search this thread for the answer.
 
-em = Engineering build. Special compiled version that enhances range and performance for the RT-N66U and will become the 'standard' build (no more separate -em version) going forward with the eagerly anticipated 374.40_0 build.
 
Thank you L&LD,

I used your wireless settings that you provided in the 38_2 thread, have you changed any of those in this version ?
 
Donation Sent.

I know it's not much but I'm sure every little bit helps. Keep on doing what you do Merlin for the community.:cool:
 
just upgraded from 38_2-em and happy to report no issues thus far. my JFFS stuff was even intact after the upgrade oddly enough.
 
Thank you L&LD,

I used your wireless settings that you provided in the 38_2 thread, have you changed any of those in this version ?

No, I haven't; but I will be doing a more intensive testing sequence with the new 40_0 firmware testing each setting individually.

What I am trying to get to is a place where the defaults (as much as possible) are also the 'best' settings.

I think v40 will be the version to revisit all these settings again.
 
I've also noticed EM-build will cause connection drops on 2.4 Ghz. I notice it when I initially flash the firmware, and don't configure my normal settings yet.

http://forums.smallnetbuilder.com/showthread.php?t=12453

Since updating RT-N66 to 39_0-em, I have also experienced several incidents of the 2.4GHz becoming unavailable. First symptom was that the SSID was no longer visible to any devices...connecting to the router GUI [using WiFi -- didn't try directly wired] was painfully slow (over 5 minutes to fully refresh)...SSH succeeded, but again VERY slow. Reboot and everything works great for a short while (1 - 3 days). I have not determined a pattern to what causes the issue.

Did not experience this with 3.0.0.4.374.35_4-sdk5.

No obvious errors in the logs.

The router is still "up", but it acts like something is consuming 100% of the CPU?

I should mention that it is operating as a Repeater connected to an AC68.
 
IPv6 and DNS Filtering

When using the Rt-N66 as a Master Browser, nonPC (iPad, iPhone and Asus EA-N66 in my setup) don't get ipv6 addresses. When shutting that feature off and restarting the devices they get their ipv6 addresses.

Also, when using DNS filtering, whatever is assigned to the repeater will apply to any devices connecting through the repeater. In my case if I default to opendns in the filtering, select none for my ipad, then the ipad is filtered using opendns.

Hopefully this helps in the testing.
 
Last edited:
That's not a bug, that's simply you trying to connect to a router that's still in the process of booting. Just let it finish its boot sequence.


Sorry for the late reply, but you can still load up a firmware and flash the device while it's in its boot sequence, which is the worrying part. Assuming the AsusWRT-Merlin router in question isn't the only way into a particular LAN, an attacker could reboot the router and upload any firmware by interrupting the boot sequence like this. Is is the presence of this vulnerability that worries me.

Of course one could say "if the attacker can even reboot the router remotely there is a problem by itself" but I prefer not to think this way. Say the router was used in a business and the attacker was able to reflash it locally, but preferred to do it this way then hard resetting the router thereby making it obvious it's been reset

Sorry this is badly worded, english is not my first language.
 
Sorry for the late reply, but you can still load up a firmware and flash the device while it's in its boot sequence, which is the worrying part. Assuming the AsusWRT-Merlin router in question isn't the only way into a particular LAN, an attacker could reboot the router and upload any firmware by interrupting the boot sequence like this. Is is the presence of this vulnerability that worries me.

Of course one could say "if the attacker can even reboot the router remotely there is a problem by itself" but I prefer not to think this way. Say the router was used in a business and the attacker was able to reflash it locally, but preferred to do it this way then hard resetting the router thereby making it obvious it's been reset

Sorry this is badly worded, english is not my first language.

If you are a business, you should use a business class product, to be honest.

You will never get the same level of security out of a home device.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top