What's new

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

Could you integrate the tinc binary with the next versions of your firmware so that it could benefit from your optimizations?

Part of my optimizations were with OpenVPN itself (that was the last optimization that increased performance by 10%), and part with OpenSSL. Entware also has the same OpenSSL optimizations, so any package from Entware should run just as fast as if I had compiled it against my own library.

What I do not understand is why entware says the package is 1.0.1c but version shows 1.0.0j

Executables in the firmware are compiled against the included OpenSSL 1.0.0, and those in Entware against the 1.0.1 version part of Entware. So if you run the openssl command part of the firmware, it will use the firmware version of the library. But anything installed from Entware that uses OpenSSL will use the 1.0.1 version that comes from Entware.
 
Thanks for the reply. I just ran some tests tonight and lzo seems to be the culprit.

When using lzo, I can achieve 19 Mbit/s decoding and 17 Mbit/s encoding when using iperf. If I tell iperf to send a H.264 testfile instead of its data, rates drop to 13 Mbit/s on both directions. Exactly the same I was experiencing before without compression.
 
Thanks for the reply. I just ran some tests tonight and lzo seems to be the culprit.

When using lzo, I can achieve 19 Mbit/s decoding and 17 Mbit/s encoding when using iperf. If I tell iperf to send a H.264 testfile instead of its data, rates drop to 13 Mbit/s on both directions. Exactly the same I was experiencing before without compression.

Make sure you set compression to Adaptive. That way, OpenVPN won't try to compress already compressed data such as video files.
 
Sadly, a lot of laptops come with the cheapest, crappiest wifi HW they can find, saving maybe 5$ on the total cost of the laptop :( That's why you see so many laptops still coming with single stream 150 Mbits interfaces. You can't always replace the antennas, but the wifi card itself is often easy to replace.
Hi,

Following the path towards replacement of the wifi card, I have purchased a small (and cheap) Wireless USB Micro Adapter from Netgear.

This fixed the hanging issue in my case and the overall network speed is much faster then with the orginal wifi card (both on 150 MBit 2.4G network). :rolleyes:

Thanks for the suggestion!

With kind regrads
Joe :cool:

PS.: The internal card could not be changed as the stupid vendor has white listed only his own wifi cards! :mad:
 
Make sure you set compression to Adaptive. That way, OpenVPN won't try to compress already compressed data such as video files.

I'm running tinc for my mesh vpn, there is no option to it. Since I get the same throughput with a H.264 file with lzo (compared to uncompressed connection), I can be sure tinc is not blindly compressing packets. I figure they simply did not bother to give you an option that can only hurt your performance.
 
Last edited:
Just one caution: too fast copying to NFS share causes router to reboot. Looks like some kernel-related stuff, can't say nothing more without serial console.
Just soldered a serial console. Here is a kernel panic message. It's appears right after
Code:
dd if=/dev/zero of=/tmp/mnt/NFS_SHARE/nonsense.swp count=1024K
command has been finished. With count=100K (50MB file) kernel panic will never rised, with count=1024K (512MB file) and more — panic is always there.
 
Just soldered a serial console. Here is a kernel panic message. It's appears right after
Code:
dd if=/dev/zero of=/tmp/mnt/NFS_SHARE/nonsense.swp count=1024K
command has been finished. With count=100K (50MB file) kernel panic will never rised, with count=1024K (512MB file) and more — panic is always there.

I have a pair of TTL Serial to USB adapters on their way from China. Should make debugging a tad easier for me (so far I've been developing pretty much blind...)

There seems to be a lot of different bug reports from the early 2.6.2x era on the web, all related to nfs_sync_mapping_wait. Maybe there's a kernel patch I missed (I applied a bunch of NFS-related patches already).

Just out of curiosity, try again with a swap file, just to see if it's a memory-related issue.
 
Bug or not?!

Hello,

I have a curious issue with clock zone of the ac66u in merlin firmware, do not remember if the official does the same.
I am in Portugal, set the time zone for Greenwich time, and the clock on the router advances an hour, you could see in the images what I mean.

Is this a bug or a bad config?
 

Attachments

  • Screen Shot 2013-03-10 at 18.08.14.jpg
    Screen Shot 2013-03-10 at 18.08.14.jpg
    39 KB · Views: 556
  • Screen Shot 2013-03-10 at 18.09.13.jpg
    Screen Shot 2013-03-10 at 18.09.13.jpg
    31.3 KB · Views: 273
I have a curious issue with clock zone of the ac66u in merlin firmware, do not remember if the official does the same.
I am in Portugal, set the time zone for Greenwich time, and the clock on the router advances an hour, you could see in the images what I mean.

I have the same issue with my RT-N66U using FW 270.25b.
Router shows 1 hour later than actual local time. My time zone is GMT+1.
 
Reboot your routers. The router probably doesn't automatically update when moving to Summer Time, rebooting should force it to resync its clock.
 
Reboot your routers. The router probably doesn't automatically update when moving to Summer Time, rebooting should force it to resync its clock.

Daylight saving time only starts 31st of March in Europe ...
 
Reboot your routers. The router probably doesn't automatically update when moving to Summer Time, rebooting should force it to resync its clock.

Reboot does not correct mine, also turned off, and on, and it stays away one hour.

Update

Set dst date manualy does the trick
 
Last edited:
I have the same issue with my RT-N66U using FW 270.25b.
Router shows 1 hour later than actual local time. My time zone is GMT+1.
Same to me!
Telnet results:
Code:
admin@RT-N66U:/tmp/home/root# date
Sun Mar 10 22:29:40 DST 2013
Router syslog (via web interface):
Code:
Mar 10 22:29:37 login[4032]: root login on 'pts/0'

As you can see it 1h ahead to my posting time...

I run GMT+1 time zone with automated DST settings.

Update:
I found a solution: By using a ntp server from my home country, found at the pool.ntp.org project, it works now correct - time jumped back one hour! :)
Maybe the issue was that I used an US ntp server - which works correct on my other Linux machines, but not on the RT-N66U AND RT-N16 router... :eek:

Here the evidence in the syslog.log:
Code:
Mar 10 22:45:11 syslogd started: BusyBox v1.20.2
Mar 10 22:45:11 notify_rc : restart_time;restart_httpd
Mar 10 22:45:11 syslogd exiting
Mar 10 22:45:11 kernel: klogd started: BusyBox v1.20.2 (2013-03-03 13:20:44 EST)
[B]Mar 10 22:45:12[/B] syslog: Password for 'admin' changed
[B]Mar 10 21:45:12[/B] RT-N66U: start httpd
Mar 10 21:45:12 start_nat_rules: apply the nat_rules!
Mar 10 21:45:12 RT-N66U: start httpd
Update 2:
The solution was not working for long: Now the time again jumped one hour ahead! :mad:

With kind regards
Joe :cool:
 
Last edited:
DST seems to be a long-standing issue with Asuswrt. I fixed a bug related to this last year, Asus also fixed quite a few bugs over the months. I guess it's still not working properly for everyone.

See if it works better if you set DST to Manual instead of Automatic - back in the day many DST issues were being resolved that way.
 
Weird "client status" behavior?

Okay, this one is kind of interesting. I've started to see weird client list behavior where I click on the Network Map page to get the client list to show up in the right hand sub-window ("Client Status" for client list), and a list of clients shows up that needs to be refreshed. So I click on "Refresh" in "Client Status" window, and get a the attached response in the "Client Status" window.

Just as a note, as one might suspect, reloading the page later (clicking on either "Reload" or "Refresh" later) doesn't refresh the client list, just gives the same error *smile*.

Any ideas what should be happening that isn't? Or what I can do to fix this? Seems like whatever should be returning the refreshed client list data isn't running at all.
 

Attachments

  • Weird client status.jpg
    Weird client status.jpg
    51.6 KB · Views: 569
Last edited:
The best solution to the europe DST is realy to set the changes to manual DST, set the change to the last sunday of march and you are done, thanks for your support guys.
 

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