See, this is the kind of things that is making things become increasingly difficult not only for me, but for some users as well. The overclock issues wouldn't have happened if it weren't for people forcing Asus's hand in locking things down.
Because people were abusing of this, the next generation of Broadcom routers now has encrypted the CFE. Piece by piece, we are losing control of our own routers. And soon, developers like me will no longer be able to do anything at all. Everyone will have to run a signed, OEM-approved firmware. It will be game over for me, Tomato, DD-WRT, OpenWRT, and every other custom router firmwares out there.
Actions have consequences. Let's be responsible. I'm not going down the line of playing cat and mouse games with manufacturers or the FCC like you are currently doing. Because this can only end one way: BADLY. For us.
The recent closing of router components have already started to make my job a hell of a lot harder now than it used to be. At this rate, it will eventually reach the breaking point where doing this will no longer be interesting, or even possible for me.
My RT-AC56U broke last week, and today I received a new one. I flashed beta2 of this said version onto it, because the Mediafire-site didn't show the stable one. It seemed to work fine, until I set an ssh key - after that it got stuck in a boot loop. I'll flash the stable version tomorrow and see if that helps. What format is the key supposed to be in anyway? There should be a tooltip with an explanation about it + it should check that the key is valid before applying it. Maybe it does that already though?
ecdsa-sha2-nistp256 AAAAE2VjZHNhLREtbmlzdHAyAAAIbmWkjWAyNTYAAABCCO76w7ajXhqWjFsoRTZ+6j3ozO9oi2Nc7G9Y8etEoP1qTb3LmsakHqHMpvN7tPVABsAhG+x7sKIOPRls8kaVRPdA= user@host
I generally agree, but this is not the whole truth. I bought an ac capable router (RT-AC66U) to escape the crowded 2,4 GHz band (13 channels in europe). But what surprise: the 5 GHz band is restricted to 4 channels, because ASUS/Broadcom were not able until now to implement DFS to open legally the whole range of the 5 GHz channels. I really understand, that this disappointment leads users to the mentioned abuse. Moreover the FCC has no jurisdiction over countries outside the USA.
Hi! This is interesting. You mean you really only have the lowest four DFS channels available (i.e. the non-DFS ones)? Is that the case with all RT-AC66 firmware versions?I generally agree, but this is not the whole truth. I bought an ac capable router (RT-AC66U) to escape the crowded 2,4 GHz band (13 channels in europe). But what surprise: the 5 GHz band is restricted to 4 channels, because ASUS/Broadcom were not able until now to implement DFS to open legally the whole range of the 5 GHz channels. I really understand, that this disappointment leads users to the mentioned abuse. Moreover the FCC has no jurisdiction over countries outside the USA.
Set "log more urgent than = Debug" and "default loglevel = Notice".
Set "log more urgent than = Debug" (determines what goes into the log)Does the first setting filter what goes into the log while second setting filters which log entries get displayed?
I also have to add that, again, chaning the icon to a custom one, makes the LAN DHCP device name to disappear...
Hi. I found a problem when editing PF with some ports in the definition. see uploaded file.
Basically, when editing the setup for a PF setting with a number of ports that goes off field, the "..." that is visualized is then also considered in the edited field...
thanks,
M
Just kept getting constant 'syn is not' error messages amongst other weirdness. Anyways, I bit the bullet and reinstalled the firmware. Still didn't work. Tried changing the NTP server to "206.108.0.131" and that did the trick.
Also, to add, I did not have any custom scripts or edited the dnsmasq in anyway (that I am aware of). Nothing unique in my setup, no ssh, no custom scripts, everything is set up via GUI only.
Will keep an eye on it and report back any issues.
Thanks Merlin!
If it does a boot loop then it's an actual bug. What's the format of the key that you pasted, so I can try to reproduce it?
The proper format is the same used by openssh (and Linux in general). It's different from the format used by SecureCRT (i.e. it's not in PEM format)
The key should look somewhat like this (this is based on my ecdsa key, an rsa key should me quite similar):
Code:ecdsa-sha2-nistp256 AAAAE2VjZHNhLREtbmlzdHAyAAAIbmWkjWAyNTYAAABCCO76w7ajXhqWjFsoRTZ+6j3ozO9oi2Nc7G9Y8etEoP1qTb3LmsakHqHMpvN7tPVABsAhG+x7sKIOPRls8kaVRPdA= user@host
-----BEGIN RSA PRIVATE KEY-----
MIIEoQIBAAKCAQEAmFcHbZ1C8327QfGIDQ8PeuUvRtmzyWwFYirT3XmHs17L17hO
7orvQp3ZvdyyV4s3DzTk2UOWuF9mm3pWa7n8LvG7hM3Mf7YHErUznqg/rGdt6W4v
7Gv8qkw7oZDt4Wk2WkWJA/tHXd2ZOPkEUciSFHgmeJC+L0EQAn1p3nlhLYVktlOg
+9L02bMwvldJQPCm2VP3Yji2XMU3CV2xJ9Vrhj6IB0SpZh2OKqzmmDl/IY8BvIa4
ZF72PP5W7P7zM1L6Z/2/vMbYXhFM0EIds+ycJQWw8JshPeIj9cv1oqOyJhEv8a1U
NaSYNmjg5gD/z6A4IZmQB1dHoIkeQrNawUOnvwIBJQKCAQB7hNWXJZA7C/+dQGB5
SntBDNo5cj6+/aOABwylvHvdiyHRgK6zkz6JCl2FL3vYR10TP6TL1e/Twvk/yvn2
ex+AAkUD5SJZti8/mdbTqwMx11Iy47gneibPRLq6WdWiAke+0Jibccspgz32175Q
JhWUDmRhwXeb75BwuLa0Ymp37la+x3WQH31G+gIo5TxhRjry6O3YgPEafAI+/dEb
OcZaMiaVTu9THml4HgCie1SnDNOG4iimQcR5zv6KUOptdRaiG/xQTvzYvXpmT4Je
9YhPODpm6zm4nfnDg3PKM8iRhjIp+qrg3HdIHADxDvYM1lyOblvV+e01fY9Ejpv5
jUGNAoGBAPKEUwzdf8SonS0eC9+fASXPQ8o9HUMSxKNQbiwJVGwibGyRSvjkdpGd
ApXtDGeLRYw7mqunoF81iwEL5+dnm/ILLgZBbJ63AUI5hsiszxinTOjSYnSsvYQm
KYMua0bEIzcem3icuDfdJvRdDbDGh+ZP7ybgAl9+jmKFrrhirwF3AoGBAKDPPcdk
CjfRA83DMLA7B9Hvin9EwLBUATuecjZr2+AWtmNXbat5AXp5hU/iyC8uqJLA90EA
ws9gJz4UXeqrHhcdaPE6cEYTN2sYjHiA7rC1nhmwWtRPlPzV98oL53yMUP845TwM
ILwq/UC0+nToMhLdu+bSoKn5m5wbqhUzVV35AoGAGjfRoIamB2wsqu590vxu06e0
TTcKFRbJJmmPXrTmiDsSo/QIGuhEK2rrhdRwCzGmp2Bjv4e+T3to+TG4NLFBSpls
wmfwESiKg7MxKnOMAqpNgPQmUc18RaNCwhLbKj63su6NWSWzDPVQUcTe4q2t07Wd
UE+Rjch+GH0npTsZ1qUCgYAvzujaadmGNzh7cWGAgECYW/i+DYVk2rRCKC/K/Xi4
PhqMPJY55bRU2AUJ6XnI1oUkteikn1yC12Wc1Z9hcSSfFpTSGErkZpPvaCnC9eYY
3AxogIm0vbasCEK/hv+hkX/dLJcthxCmpP8u6bI+bottZIP4g87mbM1lwwkNOMZa
NQKBgQC5N+9EMpCVkvrawG6tXBP+Ygmu7V5TQxKjX4ViWC0RmdgaG727ZiKcvPot
oUx8QvrGVVACR2srM4a+h1jskqLL7DcYwVO+eVpK9tiDa1GqYINX9SRuygBNNRWP
jZcIS/EHApOTb9/o1T7+qIubJcWjsVySrZM+0bLY6qrFX5Jfgw==
-----END RSA PRIVATE KEY-----
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAmFcHbZ1C8327QfGIDQ8PeuUvRtmzyWwFYirT3XmHs17L17hO7orvQp3ZvdyyV4s3DzTk2UOWuF9mm3pWa7n8LvG7hM3Mf7YHErUznqg/rGdt6W4v7Gv8qkw7oZDt4Wk2WkWJA/tHXd2ZOPkEUciSFHgmeJC+L0EQAn1p3nlhLYVktlOg+9L02bMwvldJQPCm2VP3Yji2XMU3CV2xJ9Vrhj6IB0SpZh2OKqzmmDl/IY8BvIa4ZF72PP5W7P7zM1L6Z/2/vMbYXhFM0EIds+ycJQWw8JshPeIj9cv1oqOyJhEv8a1UNaSYNmjg5gD/z6A4IZmQB1dHoIkeQrNawUOnvw== imported-openssh-key
I am getting that one too. Never happened before 378.56, is it a bug?
Oct 28 12:49:48 hour monitor: daemon is starting
Oct 28 12:49:48 hour monitor: ntp is not syn
Oct 28 12:50:18 hour monitor: daemon is starting
Oct 28 12:50:18 hour monitor: ntp is not syn
Oct 28 12:50:48 hour monitor: daemon is starting
Oct 28 12:50:48 hour monitor: ntp is not syn
Oct 28 12:51:18 hour monitor: daemon is starting
Oct 28 12:51:18 hour monitor: ntp is not syn
I have tried changing pool.ntp.org to direct IP address but that didn't resolve this issue for me.
I saw this thread but I am not really sure how to apply these changes.
Asuswrt-Merlin is now available for all supported models except for the RT-N66U (Asus hasn't released updated source code for that model yet, making it impossible for me to compile it).
We use essential cookies to make this site work, and optional cookies to enhance your experience.