What's new

Asuswrt-Merlin 378.56 Beta 1 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.
Is that mean Asus is going to discontinue the firmware development of n66u for good?

No, it simply means that Asus hasn't gotten around to upgrade all 40-ish different models they support. Give them time. They even released a beta 8xxx firmware for it a few weeks ago.
 
I'm adding the settings manually and maybe I found a bug in the Traffic Monitor Tab, Daily view. The last row of the table shows the date 01/01/2015 and the data in both Download and Upload are 0

Let me know if it's replicable, otherwise I'll post a screenshot
 
Unable to update on RT-AC68U

Perhaps Mediafire is playing up? I have tried re-downloading and re-extracted twice and it still fails
 
It's the same firewall option that has always been there on the stock firmware, just that now you aren't limited to entering a single IP, you can enter a whole subnet.
so, we still do not have option to block incoming connection over firewall? I miss that setting and hope you will add it in next releases...
 
It's looks like the NTP sync isn't working in this beta:

Oct 13 17:33:19 hour monitor: daemon is starting
Oct 13 17:33:19 hour monitor: ntp is not syn
Oct 13 17:33:49 hour monitor: daemon is starting
Oct 13 17:33:49 hour monitor: ntp is not syn
Oct 13 17:34:19 hour monitor: daemon is starting
Oct 13 17:34:19 hour monitor: ntp is not syn
Oct 13 17:34:49 hour monitor: daemon is starting
Oct 13 17:34:49 hour monitor: ntp is not syn


Time setting via SSH works fine

date -s 2015.10.13-17:38

I always used the NTP pool nl.pool.ntp.org without problems with the previous firmwares, but now this keeps trying every half a minute.

Is this a known problem or is it unique?
 
Merlin, is it safe for me to test this beta if I have quite a number of device name > 15 chars?

I read in one of your posts below that the buffer overrun issue in networkmap is still causing httpd to crash as it tries to deal with a device name longer than 15 chars.

http://www.snbforums.com/threads/of...on-3-0-0-4-378-9177.27372/page-12#post-210495

Yes. In addition to fixing most (if not all) the buffer overrun cases in networkmap, I also played it safe by telling httpd to truncate at 15 characters the device name it obtains from networkmap. That should cover at least the crashing issues.
 
What shall we do it?

Reproduce the issue with the stock firmware, then provide a detailled report to Asus in the official Asuswrt forum. I must admit I'm unable to understand the problem you are trying to describe, and I know there are quite a few users who are succesfully using Dual WAN.
 
Unable to update on RT-AC68U

Perhaps Mediafire is playing up? I have tried re-downloading and re-extracted twice and it still fails

If the zip extracts correctly and the TRX inside the zip has the correct model name, then it's not an issue with Mediafire. Zipfiles are CRC-checked, so any corrupted file would fail to extract.

Try the usual: reboot with no USB disk plugged, try a different browser or a different computer. If it still fails, do a factory default reset, upgrade, then reconfigure your router. You might be able to restore a saved config if you are only going from 378.55 to 378.56 beta 1.
 
It's looks like the NTP sync isn't working in this beta:

Oct 13 17:33:19 hour monitor: daemon is starting
Oct 13 17:33:19 hour monitor: ntp is not syn
Oct 13 17:33:49 hour monitor: daemon is starting
Oct 13 17:33:49 hour monitor: ntp is not syn
Oct 13 17:34:19 hour monitor: daemon is starting
Oct 13 17:34:19 hour monitor: ntp is not syn
Oct 13 17:34:49 hour monitor: daemon is starting
Oct 13 17:34:49 hour monitor: ntp is not syn


Time setting via SSH works fine

date -s 2015.10.13-17:38

I always used the NTP pool nl.pool.ntp.org without problems with the previous firmwares, but now this keeps trying every half a minute.

Is this a known problem or is it unique?

Works for me. Are you in Router mode? What type of WAN connection? Using either a VPN client or custom DNS settings?
 
so, we still do not have option to block incoming connection over firewall? I miss that setting and hope you will add it in next releases...

What are you trying to block exactly? By default the firewall will reject any inbound connection unless you specifically opened the port through a Virtual Server or UPNP.
 
At the risk of being banished from the planet, I must announce an update to the previously long-winded discussion regarding USB-printer support. As it turns out, the printer-sharing feature is alive and well :D on asuswrt-merlin-378.56_beta1, the official asuswrt 378_9155 and, I suspect, the other previous versions of merlin's fork of the fw as well.

I had complained about a flood of error messages being continuously printed out every time a print job was sent to the USB-printer attached to my Asus AC56U router with merlin-378.55_beta1. Yesterday, after I had reverted to the official asuswrt firmware to troubleshoot the printer-sharing feature, I used nmap on my laptop to see the open common ports on the clients on my network:
Code:
# nmap -T4 -F 192.168.1.0-2

The router displayed two ports related to the printer service:
Code:
192.168.1.1
Host is up (0.0065s latency).
Not shown: 94 closed ports
PORT  STATE SERVICE
53/tcp  open  domain
80/tcp  open  http
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
515/tcp  open  printer
9100/tcp open  jetdirect

Anyway, long story short, I had been using the socket://192.168.1.1:9100 path to the printer; changing the configuration on my laptop (CUPS-server) to point to lpd://192.168.1.1:515/AUTO finally resulted in SUCCESS!
 
Last edited:
Works for me. Are you in Router mode? What type of WAN connection? Using either a VPN client or custom DNS settings?

I'm in Wireless router mode with a PPPoE IPv4 fiber connection with an 6in4 tunnel from Hurrican Electric and I use the DNS servers from xiala.net. My workstation uses the same DNS settings and there the sync runs just fine
 
It's looks like the NTP sync isn't working in this beta:

Oct 13 17:33:19 hour monitor: daemon is starting
Oct 13 17:33:19 hour monitor: ntp is not syn
Oct 13 17:33:49 hour monitor: daemon is starting
Oct 13 17:33:49 hour monitor: ntp is not syn
Oct 13 17:34:19 hour monitor: daemon is starting
Oct 13 17:34:19 hour monitor: ntp is not syn
Oct 13 17:34:49 hour monitor: daemon is starting
Oct 13 17:34:49 hour monitor: ntp is not syn


Time setting via SSH works fine

date -s 2015.10.13-17:38

I always used the NTP pool nl.pool.ntp.org without problems with the previous firmwares, but now this keeps trying every half a minute.

Is this a known problem or is it unique?

I had the exact same problem this morning on my RT-AC87R after I upgraded the firmware. Turns out I had to change the DNS servers under Advanced Settings WAN/Internet Connection/WAN DNS Setting. Once I did that ntp picked up from pool.ntp.org

Not sure why this would trigger it but it worked for me.
 
Works for me. Are you in Router mode? What type of WAN connection? Using either a VPN client or custom DNS settings?
Was going to send you a note (or finally figure out how to do a pull request)....

in ntp.c they declare the arg array for starting the ntpclient before they set the referenced server string.....I think the results are unpredictable (it hard failed on my fork)
Code:
126 int ntp_main(int argc, char *argv[])
127 {
128     FILE *fp;
129     pid_t pid;
130     char *args[] = {"ntpclient", "-h", server, "-i", "3", "-l", "-s", NULL};
131
132     strcpy(server, nvram_safe_get("ntp_server0"));
 
Was going to send you a note (or finally figure out how to do a pull request)....

in ntp.c they declare the arg array for starting the ntpclient before they set the referenced server string.....I think the results are unpredictable (it hard failed on my fork)
Code:
126 int ntp_main(int argc, char *argv[])
127 {
128     FILE *fp;
129     pid_t pid;
130     char *args[] = {"ntpclient", "-h", server, "-i", "3", "-l", "-s", NULL};
131
132     strcpy(server, nvram_safe_get("ntp_server0"));

In theory it should be fine. args[] will contain a pointer to the server char buffer, so if you change the content of the buffer later on, the pointer still remains valid. Unless there's some compiler optimization where it puts the content of the buffer inside the array instead of just a pointer to it.

That would be easy to test, doing a logmessage() of the content of the array before and after the strcpy()
 
In theory it should be fine. args[] will contain a pointer to the server char buffer, so if you change the content of the buffer later on, the pointer still remains valid.
Didn't work that way for me :) Hard failed until I swapped the lines....you can see later on they make an explicit update by writing to args[2] to update it.....
 
Didn't work that way for me :) Hard failed until I swapped the lines....you can see later on they make an explicit update by writing to argv[2] to update it.....

Might be something I misunderstood on how arrays are defined in C then. Shouldn't be a problem to play it safe and update the array content.
 
Status
Not open for further replies.

Similar threads

Sign Up For SNBForums Daily Digest

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