What's new

Asuswrt-Merlin 378.55 is now available

  • 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.
@RMerlin
I can't execute scripts with firmware v378.55, is something changed?
Code:
echo $0
-sh
If I change to /bin/sh it's ok but temporary, won't survive reboot and I can't put exec /bin/sh in /jffs/scripts/init-start because will not be executed
Code:
exec /bin/sh
echo $0
/bin/sh
I found the culprit, I have to add path to non working scripts
Code:
PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I still wondering why worked before and now not.
 
I updated three days ago, I have noticed in the past 3 days each morning I have had to reboot the RT-ac66u to get connection back to my PC. I get the dang APIPA Default as I cannot get connected to the router. All devices fail to get internet or an IP. I cannot ping the Bridge (ac66u) nor the AP. Of course this is from the APIPA so no worries. I have had to reboot the 66u each morning to get an IP. Thinking of moving back to previous build which was 54-2 beta. I may just try defaulting all and seeing what happens

Set is simple
AP = RT-ac68u
Wireless Bridge = RT-ac66u (To AP)
Netgear Prosafe router to 66
PC, Printer, 2 VoiP, 1 WyseP25, Linux Mint box connected to 66U

And for the record, I see nothign out of the ordinary in the logs of either router. Stilllooking at logs on Windows
 
I updated three days ago, I have noticed in the past 3 days each morning I have had to reboot the RT-ac66u to get connection back to my PC. I get the dang APIPA Default as I cannot get connected to the router. All devices fail to get internet or an IP. I cannot ping the Bridge (ac66u) nor the AP. Of course this is from the APIPA so no worries. I have had to reboot the 66u each morning to get an IP. Thinking of moving back to previous build which was 54-2 beta. I may just try defaulting all and seeing what happens

Set is simple
AP = RT-ac68u
Wireless Bridge = RT-ac66u (To AP)
Netgear Prosafe router to 66
PC, Printer, 2 VoiP, 1 WyseP25, Linux Mint box connected to 66U

And for the record, I see nothign out of the ordinary in the logs of either router. Stilllooking at logs on Windows
Is your PC connected via wireless 2.4 GHz? That sounds like the issue I had; basically 2.4 GHz connections would drop and no longer reconnect without a reboot. 5 GHz and wired connections were fine. I ended up going back to 378.54_2 and have had no issues.
 
Is your PC connected via wireless 2.4 GHz? That sounds like the issue I had; basically 2.4 GHz connections would drop and no longer reconnect without a reboot. 5 GHz and wired connections were fine. I ended up going back to 378.54_2 and have had no issues.
No the PC is hardwired to the ac66 the 66 is Bridged 5ghz to the 68u. Connection there is 1300/1300 so no issues at all on that

Actually is is this

Clients connect to a Netgear Prosafe GS108e (unmanaged)
Prosafe connects to RT-ac66u
RT-ac66u is Media Bridged to RT-ac68u (5Ghz)

As noted I never had this issue until 55_0
 
Last edited:
I found the culprit, I have to add path to non working scripts
Code:
PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I still wondering why worked before and now not.

There's been no change to Busybox. Make sure it's not one of your scripts modifying the default search path.
 
No the PC is hardwired to the ac66 the 66 is Bridged 5ghz to the 68u. Connection there is 1300/1300 so no issues at all on that

Actually is is this

Clients connect to a Netgear Prosafe GS108e (unmanaged)
Prosafe connects to RT-ac66u
RT-ac66u is Media Bridged to RT-ac68u (5Ghz)

As noted I never had this issue until 55_0

Media Bridge has never worked reliably. Some users were even told by Asus's tech support to avoid it if it didn't work for them.

It's all Broadcom and Asus's code, and outside of my control. The randomness of it goes years back. And to make things even more annoying, some people reported that somehow 378.55 works BETTER for them in media bridge mode than past releases, and for others it's the opposite.

So if you have any media bridge issues, either take it to Asus, or avoid using it (as they've suggested in the past).
 
Media Bridge has never worked reliably. Some users were even told by Asus's tech support to avoid it if it didn't work for them.

It's all Broadcom and Asus's code, and outside of my control. The randomness of it goes years back. And to make things even more annoying, some people reported that somehow 378.55 works BETTER for them in media bridge mode than past releases, and for others it's the opposite.

So if you have any media bridge issues, either take it to Asus, or avoid using it (as they've suggested in the past).

I never said I was having issues with Media Bridge. I stated I was having issues with getting an IP address after upgrading to 55_0. Since the update each morning I fire up my PC and I am unable to connect APIPA address comes of course. However, my VoIP phones are all connected Same Switch, Same 66. My WyseP25 cannot obtain a IP either. The common factor here? The Wyse and PC get shut down each night, while the Two VoIP phones stay constant on

What is this telling me? It tells me that a client constantly on doing its DHCP refresh (Via Bridge to controlling AP) is perfect, however it seems clients that get shut down, then power up after some time cannot get an IP address renew even if that address is in the reservation

Assumptions are
55_0 DHCP cache or ? changed
Bad NIC/Cat5 on PC/Wyse (Hardly)
I am full of shirt and it is alien dna causing my mind to flounder


UPDATE 1:33PM PST
I reverted back to the last stable build. Wireless 2.4 was also having connection issues. All started with 55_0. I will wait for 55_1
 
Last edited:
What's with the Softpedia website!! Only way I could D/L the 378.55 firmware was through them. Now I have to submit my user and password for the router. Only thing is, I don't know remember my user name for the router. I never had to use it before! What BS!! Only because I can't access Merlin's latest firmware update, non-beta from Merlin's firmware page! WTF! Never had this issue before!!
 
Jul 25 00:42:06 dnsmasq-dhcp[280]: DHCPNAK(br0) (mac address) wrong address

This been poping up on few devices , dont know what means cause those device are connect to wifi and working correct. i should probably stop looking at that system logs, though i did seem to fix the dns query max log i was getting
 
Last edited:
Jul 25 00:42:06 dnsmasq-dhcp[280]: DHCPNAK(br0) (mac address) wrong address

This been poping up on few devices , dont know what means cause those device are connect to wifi and working correct. i should probably stop looking at that system logs, though i did seem to fix the dns query max log i was getting

It's normal. Your mobile phone was probably connected to another Wi-Fi network, and when you got home it requested the IP address from the other Wi-Fi network which your router is rejecting with a DHCP NACK (negative acknowledgmement) because that IP address is for a different sub-net.

E.g, on my router:

Jul 23 18:16:22 dnsmasq-dhcp[474]: DHCPNAK(br0) 192.168.0.13 (phone MAC addr) wrong address

I got home at 18:16, and the IP address 192.168.0.13 was from the free Wi-Fi at the bar. My normal IP address for that device is 10.0.1.216.
 
The 5 GHz channel strength is a bit weaker on this merlin build than stock 3.0.0.4.378_6117.

Not sure if there is any difference in the drivers.

To my television with no changes in placement of router or television doing a full reset after upgrading firmware I get the following.

Merlin: -51 to -53

Stock: -47 to -49

May need to test another build when I get a chance.
 
Thank you for providing this version. It's working fine on my RT-AC87U.

Unfortunately, there is still a small none-critical but confusing me bug with manual IP address assignments with DHCP. When client's hostname (usually used as client id) doesn't match reservation's client name case sensitive, client's IP address will be shown as "Manual" under "Network map -> Clients -> View list".

Reservation:
upload_2015-7-26_12-42-41.png


Client list:
upload_2015-7-26_12-38-54.png


(MAC address truncated shown in both screenshots)

Best regards,
begemot
 
What's with the Softpedia website!! Only way I could D/L the 378.55 firmware was through them. Now I have to submit my user and password for the router. Only thing is, I don't know remember my user name for the router. I never had to use it before! What BS!! Only because I can't access Merlin's latest firmware update, non-beta from Merlin's firmware page!...
What is the question, exactly?
 
I never said I was having issues with Media Bridge. I stated I was having issues with getting an IP address after upgrading to 55_0. Since the update each morning I fire up my PC and I am unable to connect APIPA address comes of course. However, my VoIP phones are all connected Same Switch, Same 66. My WyseP25 cannot obtain a IP either. The common factor here? The Wyse and PC get shut down each night, while the Two VoIP phones stay constant on

What is this telling me? It tells me that a client constantly on doing its DHCP refresh (Via Bridge to controlling AP) is perfect, however it seems clients that get shut down, then power up after some time cannot get an IP address renew even if that address is in the reservation

Assumptions are
55_0 DHCP cache or ? changed
Bad NIC/Cat5 on PC/Wyse (Hardly)
I am full of shirt and it is alien dna causing my mind to flounder


UPDATE 1:33PM PST
I reverted back to the last stable build. Wireless 2.4 was also having connection issues. All started with 55_0. I will wait for 55_1

Update 24 hours almost later
Normal to report. Reverting back to last stable build No issues at all. Go figure. All Wifi 2.4 connected, Media Bridge perfect and PC booted up to its reservation IP. Life is good. Yup 55_0 has an issue at least in my setup with DHCP
 
What's with the Softpedia website!! Only way I could D/L the 378.55 firmware was through them. Now I have to submit my user and password for the router. Only thing is, I don't know remember my user name for the router. I never had to use it before! What BS!! Only because I can't access Merlin's latest firmware update, non-beta from Merlin's firmware page! WTF! Never had this issue before!!

I just finished downloading third firmware file (just for testing purposes), and not a single time I was asked by Softpedia my router's login credentials. If you meant you're being asked your login name and password by your router... well, isn't that how it's supposed to be? Of course you have to provide those information. That's the only way router knows it's you and not some outsider trying to breach your router's configuration page and make unimaginable mess. It's a security measure and while it's not perfect, it's the best we have at the moment (especially the most recent one using tokens based scheme instead of http basic authentication).
 
Router RT-AC68U software Merlin 378.55-syslog-a general log

Jul 26 01:23:37 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:42 kernel: net_ratelimit: 100 callbacks suppressed
Jul 26 01:23:42 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
.............................................
........................


What is this ?
 

Attachments

  • xxx.jpg
    xxx.jpg
    83.7 KB · Views: 400
Router RT-AC68U software Merlin 378.55-syslog-a general log

Jul 26 01:23:37 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:38 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
Jul 26 01:23:42 kernel: net_ratelimit: 100 callbacks suppressed
Jul 26 01:23:42 kernel: TCP: Possible SYN flooding on port 1723. Sending cookies.
.............................................
........................


What is this ?
Its a SYnc Flood attack (Possibly) some one something is whopping it up on yoru interface looking to get in
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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