What's new

Asuswrt-Merlin - custom build of the Asus RT-N66U firmware

  • 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.
Has anybody had trouble with port forwarding

More specifically - Ive forwarded the ports I needed but then when going to a website on one of those ports through the WAN address - something happens and the wireless gets kicked off / it seems like the router is rebooting

When Ive tried the same on another connection through a different ISP there does not see to be a problem and the router stays online with no issues.....very odd

Not sure if this makes any sense and not at home at the moment to test but will be looking at when I get home
 
Today i want to try your firmware, but can I install it from tomato like a tomato firmware or flash back to an Asus Firmware and then install yours?

And is a NVRAM erase needed?
 
Today i want to try your firmware, but can I install it from tomato like a tomato firmware or flash back to an Asus Firmware and then install yours?

And is a NVRAM erase needed?

Do the same procedure you would normally do when going from Tomato to Asus firmware. No need to flash Asus firmware first, as for all intent and purposes my firmware is the same. I would also recommend doing an NVRAM erase before, and after flashing.
 
Has anybody had trouble with port forwarding

More specifically - Ive forwarded the ports I needed but then when going to a website on one of those ports through the WAN address - something happens and the wireless gets kicked off / it seems like the router is rebooting

When Ive tried the same on another connection through a different ISP there does not see to be a problem and the router stays online with no issues.....very odd

Not sure if this makes any sense and not at home at the moment to test but will be looking at when I get home

I've seen a few isolated reports of issues with port forwarding on the Asus firmware (not specific to my mods) on the Asus forums. Some people fixed it by resetting to factory defaults and reconfiguring - probably a leftover problem from another firmware versions they previously ran.

Also check how much nvram you have left (run "nvram show" over telnet). This router has the reputation of becoming unstable if nvram gets too full.
 
Thank you!!!!
It's possible add this page in your modded fw?

:D

I could, just not sure if it's a good idea as people will then start asking me why the fan control (for the non-existent fan) doesn't do anything :D
 
Next version will allow you to save your traffic history to disk (either USB or JFFS - the former is recommended), and I also added back the Monthly traffic page that Asus had removed from the original Tomato firmware on which they based their traffic monitoring.
 
Good news everyone! Asus has answered people reporting the 32K NVRAM, and they have not only confirmed the issue, but said they would fix it in a future update (bumping it to 64K as intended), tentatively scheduled for June :)
 
Eric, I'm unable to compile the firmware anymore after wol was added to it. I've been trying whole evening but it keeps hitting one or the other error while compiling wol. e.g. redefinition of struct ether_addr (which i fixed by modifying configure.ac to move around some checks which were over writing couple of defines to 0 even though the struct was found in another header), undefined reference to rpl_malloc from lintl (also, earlier it was using external lintl then suddenly started compiling internal lintl), mipsel-uclibc-strip quitting, complaining that wol is of different arch (and true enough, wol was reported to be my host machine arch amd-64 by readelf instead of mips). I've tried lot of changes, fresh sync and everything but the only thing that doesn't compile is wol. If I dont compile wol, then rest of the firmware compiles fine.

Any suggestions as to if I'm missing anything? or maybe you missed uploading something to git?
 
Eric, I'm unable to compile the firmware anymore after wol was added to it. I've been trying whole evening but it keeps hitting one or the other error while compiling wol.

Any suggestions as to if I'm missing anything? or maybe you missed uploading something to git?

I remember having run into that problem as well, but I can't remember what I did to fix it. I'd have to look again when I get back home. At worse I'll re-add my whole router/wol folder again to the repo.
 
RMerlin

First, thanks for taking the time to code and share these custom firmwares. Its definitely added value for many N66U users.

I tried your .108RM4 release. In particular for the HTTPS login to GUI. When left at HTTP it works as intended. I am required to provide login credentials to enter GUI. Great.

I then changed to HTTPS only. From that time onwards anytime I typed https://router_ip I would go directly into the admin GUI with NO credentials required.

I tried defaulting the router, resetting the NVRAM and tried changing the password but nothing would allow HTTPS to require credentials.

Any ideas?
 
I then changed to HTTPS only. From that time onwards anytime I typed https://router_ip I would go directly into the admin GUI with NO credentials required.

I tried defaulting the router, resetting the NVRAM and tried changing the password but nothing would allow HTTPS to require credentials.

Any ideas?

Sounds like Asus did something really silly in the web server code... I'll have to track down why they disable authentication when running as https. I do see some code where they disable authentication under certain circumstances, I will have to look deeper to figure out why.
 
Sounds like Asus did something really silly in the web server code... I'll have to track down why they disable authentication when running as https. I do see some code where they disable authentication under certain circumstances, I will have to look deeper to figure out why.

Thanks. At this point switching to HTTPS isn't really a security improvement...
 
Thanks. At this point switching to HTTPS isn't really a security improvement...

I agree. Asus's code is broken, I will have to fix it. I do see for instance a logic check that is impossible to happen... Thanks for the heads up.
 
Fixed, will be included in the next release. From what I gathered, Asus took the existing code, disabled https, and started adding stuff on it without updating the https parts of the code. There was also a little gem where it would skip authentication if the port was different from 443 OR different from 80. Which is simply, uh, impossible to happen :)
 
Any suggestions as to if I'm missing anything? or maybe you missed uploading something to git?

I just did a checkout of the wol directory (after removing my local copy), and ran "make wol" from the router/ folder, and it compiled fine for me. What happens if you do "make wol-clean" followed with "make wol" (still from inside the router/ folder)?

Now that I remember, the issues I had here were with the .po files, so they were different from you.
 
Fixed, will be included in the next release. From what I gathered, Asus took the existing code, disabled https, and started adding stuff on it without updating the https parts of the code. There was also a little gem where it would skip authentication if the port was different from 443 OR different from 80. Which is simply, uh, impossible to happen :)

I had set mine to port 443. So, I hope its really fixed. Thanks for the quick reply. If you want to send the beta to test I'm happy to do so. Just do it soon as I may not keep the N66U past next week.
 
I just did a checkout of the wol directory (after removing my local copy), and ran "make wol" from the router/ folder, and it compiled fine for me. What happens if you do "make wol-clean" followed with "make wol" (still from inside the router/ folder)?

Now that I remember, the issues I had here were with the .po files, so they were different from you.

I just did a fresh clone of your branch and still the same errors. Tried make wol-clean followed by make wol and still same errors.
First error is about ether_addr redefinition (able to bypass this by modifying configure.ac)
Second error which I'm stuck on is undefined symbol rpl_malloc. This seems to be quite a common issue. I tried all the remedies suggested online but still facing this problem. On looking through the config files, it looks like malloc is defined to rpl_malloc whenever cross compiling is done.
 
I just did a fresh clone of your branch and still the same errors. Tried make wol-clean followed by make wol and still same errors.
First error is about ether_addr redefinition (able to bypass this by modifying configure.ac)
Second error which I'm stuck on is undefined symbol rpl_malloc. This seems to be quite a common issue. I tried all the remedies suggested online but still facing this problem. On looking through the config files, it looks like malloc is defined to rpl_malloc whenever cross compiling is done.

Delete wol/stamp-h1, and make sure you do rebuild the configure file. The parent makefile should take care of this:

wol/stamp-h1:
ac_cv_func_malloc_0_nonnull=yes cd $(TOP)/wol && $(CONFIGURE) --host=mips --prefix=$(INSTALLDIR)/wol CC=mipsel-uclibc-gcc ST
RIP=mipsel-uclibc-strip AR=mipsel-uclibc-ar LD=mipsel-uclibc-ld NM=mipsel-uclibc-nm RANLIB=mipsel-uclibc-ranlib
touch wol/stamp-h1
 
Delete wol/stamp-h1, and make sure you do rebuild the configure file. The parent makefile should take care of this:

Just fixed this issue and sent you a pull request on github. The issue is slightly different. Here is the explanation:

There are three issues:
1. The variable in makefile to suppress the usage of rpl_malloc should be jm_cv_func_working_malloc, not ac_cv_func_working_malloc. The latter is used when the autotools macro for rpl_malloc test is used. But wol has its own test based on former variable. (Can check this in aclocal.m4)

2. In the rule to run configure for wol, we need to cd to the wol directory first and then set the variable and run configure otherwise the variable value that is set by us doesn't stick.

3. The config.h.in macros in configure.ac corresponding to the ether_addr struct should be kept before its corresponding tests, otherwise the config.h.in has the default values after the tests and override them even if the tests are successful, leading to wol trying to use its own inbuild ether_addr definition and failing with a redefinition error.
 
Just fixed this issue and sent you a pull request on github. The issue is slightly different. Here is the explanation:

Merged in. Thanks :)

Here, I just spent nearly 6 hours trying to figure out why you can't upload a firmware or a settings file over HTTPS. For some reason, the file stream opened with ssl_server_fopen() has no file descriptor associated to it, despite being fully valid. I can't find any explanation or workaround, so I give up on this for now, and will just disable uploading a firmware/settings file over https. Asus' httpd code is a maze compared to Tomato's simple and clean httpd code :(
 
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