What's new

Asuswrt-Merlin 374.40 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!

Status
Not open for further replies.
Hi All,

I just upgraded... to the newest Beta3 version, and I'm on the AC68U... Just got a reboot. Are there logs I can send? I think this is the "random reboot" issue.
 
Just to make sure I read correctly, but what you are saying is there is no way to get what the nvram_dump returns from command line and you must use printf's to view the value at the time?

Correct. Functions like nvram_dump are handled on-the-fly by the httpd daemon as it parses the page before pushing it to clients, dynamically replacing those %< >% tag with content generated by the function referred there. It's done at parse time, so it can't be directly invoked.

I'll take a look at that function at some point (don't have time today) to see if a potential bug can be seen in the code.
 
Hi All,

I just upgraded... to the newest Beta3 version, and I'm on the AC68U... Just got a reboot. Are there logs I can send? I think this is the "random reboot" issue.

Unfortunately, the only log that would yield any useful information would be the output from the internal serial port. Kernel oops info gets dumped to that serial port.
 
Missing 5Ghz Channel

Minor bug report - 5GHz Channel 161 is missing from drop down list when 40 MHz bandwidth is selected. Looks like an Asus bug. Problem also present on RT-N66U_3.0.0.4_374_4561.
 
dsring, I can confirm that also.

However in my testing, the lower 5GHz channels give superior performance than the higher channels (channel 44 or 48 gives almost 20% higher throughput and more consistent throughput than channel 161 for me).

So, while it is a bug, it is an beneficial one imo. ;)
 
Correct. Functions like nvram_dump are handled on-the-fly by the httpd daemon as it parses the page before pushing it to clients, dynamically replacing those %< >% tag with content generated by the function referred there. It's done at parse time, so it can't be directly invoked.

I'll take a look at that function at some point (don't have time today) to see if a potential bug can be seen in the code.

I believe I found the bug.

I verified that it was the following line causing the issue as putting a default value of "" in there made the page load just fine:

Code:
<input type="hidden" name="status_openvpnd" value="<% nvram_dump("openvpn_connected",""); %>">

When you said you needed to dig down into the nvram_dump code, I went down that trail and it ended up calling the following code in openvpn_options.c where unit is the server that's on (mine was 1):

Code:
void parse_openvpn_status(int unit){
	FILE *fpi, *fpo;
	char buf[512];
	char *token;

	sprintf(buf, "/etc/openvpn/server%d/status", unit);
	fpi = fopen(buf, "r");

	sprintf(buf, "/etc/openvpn/server%d/client_status", unit);
	fpo = fopen(buf, "w");

	if(fpi && fpo) {
		while(!feof(fpi)){
			CLEAR(buf);
			if (!fgets(buf, sizeof(buf), fpi))
				break;
			if(!strncmp(buf, "CLIENT_LIST", 11)) {
				//printf("%s", buf);
				token = strtok(buf, ",");	//CLIENT_LIST
				token = strtok(NULL, ",");	//Common Name
				token = strtok(NULL, ",");	//Real Address
				fprintf(fpo, "%s ", token);
				token = strtok(NULL, ",");	//Virtual Address
				fprintf(fpo, "%s ", token);
				token = strtok(NULL, ",");	//Bytes Received
				token = strtok(NULL, ",");	//Bytes Sent
				token = strtok(NULL, ",");	//Connected Since
				token = strtok(NULL, ",");	//Connected Since (time_t)
				[B]token = strtok(NULL, ",");	//Username, include'\n'[/B]
				fprintf(fpo, "%s", token);
			}
		}
		fclose(fpi);
		fclose(fpo);
	}
}

The line I have bolded is the issue. The comment claims this will include \n Took me some time to find an old C compiler and ran the line that would go down this loop which is the following (removed IP addresses):

Code:
HEADER,CLIENT_LIST,Common Name,Real Address,Virtual Address,Bytes Received,Bytes Sent,Connected Since,Connected Since (time_t),Username
CLIENT_LIST,client1,XXX.XXX.XXX.XXX:XXXXX,,159978824,122711088,Sun Mar  9 22:44:19 2014,1394423059,UNDEF

Because there is no ending comma, that last strtok does not work. The compile I used was smart enough to put null but I'm supposing whatever compiler this is using is just blowing up with a segmentation fault.

I changed that file and popped a , after the UNDEF and it opened the page ultimately populating that variable with my IP address.

I'm not sure if fixing the strtok line or adding a comma to the status file would be easier but either way that is what is causing the issue.

Hope that helps! Either way it was just not allowing me to go to that page which really doesn't have any functions I need to use so I'm ok for now. I'm just glad to find the issue is within the page itself and not somewhere else.
 
Minor bug report - 5GHz Channel 161 is missing from drop down list when 40 MHz bandwidth is selected. Looks like an Asus bug. Problem also present on RT-N66U_3.0.0.4_374_4561.

The list of available 40 MHz channel in the firmware code stops at 157, so either that's because 161 is assumed to only be used while bonded with 157 (since 161 is present in the 20 MHz array), or for some odd reason they forgot to add it to the array.
 
I'm not sure if fixing the strtok line or adding a comma to the status file would be easier but either way that is what is causing the issue.

Hope that helps! Either way it was just not allowing me to go to that page which really doesn't have any functions I need to use so I'm ok for now. I'm just glad to find the issue is within the page itself and not somewhere else.

That does make sense. I'm not sure why Asus implemented this particular parser with a bunch of strtok rather than a regexp like is usually used elsewhere, I might rewrite it to use regexp instead if it would make it more robust.
 
HI guys

Let me ask you something, @Merlin if you can answer me i would be pleasured :)

i have the RTAC 68U and always used your FW , but i made a factory reset and i`m using to test the latest one released by Asus and something weird is happening

Sometimes the router appears to stop responding and my connection just drops, i`m using the dual wan here with load balance, and sometimes when i ask the router to reboot when it comes online again just do not work, the wifi leds not goes on and i have to turn off the router power and turn on again to comes online

Have you ever heard this kind of tings made by a FW or this could be a Hardware issue?

Thanks ;)
 
IPv6 Firewall

Upgraded last night on an RT-N66U (from 39_em) and generally everything seems to be running fine.

I normally run a few port scan tests after each upgrade just to see everything looks OK. IPv4 seems fine.

Using http://ipv6.chappell-family.com/ipv6tcptest/ I got this result

ICMPv6 ECHO REQUEST returned : ECHO REPLY

Everything else came back as stealth. I thought (but I am not 100% certain) that ICMPv6 test came back as stealth with the earlier firmware releases.

Is this an expected result?

IPv6 firewall is enabled with default settings.
 
Hi Merling,
That limit is large enough to support a 4096-bit certificate. If your certificate needs more than that, then your certificate is way overkill for this router.

The limit was decided by me as a balanced value. Increasing that limit would significantly increase memory usage.

my certificate has only 1024bit.
This is the format only with changed Numbers:
Code:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DE, ST=myvpnca, L=xxx, O=xxx, CN=xxx CA/emailAddress=xxx@xxx.de
        Validity
            Not Before: Aug  6 11:39:09 2007 GMT
            Not After : Aug  3 11:39:09 2017 GMT
        Subject: C=DE, ST=CA, L=xx, O=xx, CN=s.xx/emailAddress=xxx@xxx-xx.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
                    22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
                    22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
                    22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
                    22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
                    22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
                    22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
                    22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
                    22:22:22:22:22:22:22:22:22
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                Easy-RSA Generated Certificate
            X509v3 Subject Key Identifier: 
                22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22
            X509v3 Authority Key Identifier: 
                keyid:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22
                DirName:/C=DE/ST=xxx/L=xxx/O=xxx/CN=xxx CA/emailAddress=xx@xx-xx.de
                serial:22:22:22:22:22:22:22:22

            X509v3 Extended Key Usage: 
                TLS Web Client Authentication
            X509v3 Key Usage: 
                Digital Signature
    Signature Algorithm: sha1WithRSAEncryption
        22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
        22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
        22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
        22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
        22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
        22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
        22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:22:
        22:22
-----BEGIN CERTIFICATE-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END CERTIFICATE-----

Or is it enough to copy the Part from BEGIN CERTIFICATE and END CERTIFICATE?
 
beta3 caused random reboots for me too. reverted back to alpha4 solved the problem and i dont think i'll touch it for a while longer as i am very satisfied with the reliability and the performance .
 
68R b3: Almost 5 days and stable as a rock. I have a LOT of devices connected to it. Even 2 switches.

Uptime 4 days 22 hours 47 minutes 18 seconds
Temperatures 2.4 GHz: 52°C - 5 GHz: 53°C - CPU: 82°C
 
Upgraded last night on an RT-N66U (from 39_em) and generally everything seems to be running fine.

I normally run a few port scan tests after each upgrade just to see everything looks OK. IPv4 seems fine.

Using http://ipv6.chappell-family.com/ipv6tcptest/ I got this result

ICMPv6 ECHO REQUEST returned : ECHO REPLY

Everything else came back as stealth. I thought (but I am not 100% certain) that ICMPv6 test came back as stealth with the earlier firmware releases.

Is this an expected result?

IPv6 firewall is enabled with default settings.

Nothing has been changed to the IPv6 firewall.

The reason why I don't drop PING requests is because according to the RFC, an IPv6 host is expected to respond to ping requests. Dropping those packets would therefore be in violation of RFCs.
 
Or is it enough to copy the Part from BEGIN CERTIFICATE and END CERTIFICATE?

Your answer lies in your very own quote, from your first message:

Keys and Certificates

Code:
Only paste the content of the ----- BEGIN xxx ----- / ----- END xxx ----- block (including those two lines).

Limit: 3499 characters per field
 
Yes of course I'm blind.
Such a thing is called in Germany operating blind.
This is me now but a little embarrassing.

Now it works.
 
Upgraded last night on an RT-N66U (from 39_em) and generally everything seems to be running fine.

I normally run a few port scan tests after each upgrade just to see everything looks OK. IPv4 seems fine.

Using http://ipv6.chappell-family.com/ipv6tcptest/ I got this result

ICMPv6 ECHO REQUEST returned : ECHO REPLY

Everything else came back as stealth. I thought (but I am not 100% certain) that ICMPv6 test came back as stealth with the earlier firmware releases.

Is this an expected result?

IPv6 firewall is enabled with default settings.

Nothing has been changed to the IPv6 firewall.

The reason why I don't drop PING requests is because according to the RFC, an IPv6 host is expected to respond to ping requests. Dropping those packets would therefore be in violation of RFCs.
I'm still running 39_0-em and that test page reflects "stealth"(GREEN) on all ports, is something setup wrong on mine then?
 
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