What's new

Asuswrt-Merlin 3.0.0.4.354.28 Beta 1

  • 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.
How to enable execution of commands:

modprobe -q iptable_mangle
modprobe -q xt_HL
iptables -t mangle -D PREROUTING -i wlan0 -p udp -j TTL --ttl-inc 1
iptables -t mangle -A PREROUTING -i wlan0 -p udp -j TTL --ttl-inc 1

It is necessary that worked my IPTV box.
 
I'm having some real issues with the WiFi connection using both 3.0.0.4.354.27 BETA and 3.0.0.4.354.28 BETA on my Asus RT-AC66U.


I'm connected to my MacBook Pro 15" Retina model using 5.0GHz 802.11n 3x3 450mbps connection and it's dropping out several times a day now.

It's not due to poor reception, I'm in a small space with a range of approximately 4-8 meters from the router at all times, resulting in Mac OS X Mountain Lion normally reporting 450mbps connect at all times.

I've tweaked the settings somewhat, putting it in N-only mode, AES only, OFDM 54 multicast rate, Short Preamble, 80 beacon interval, TX Bursting, Multicast Forwarding and WMM APSD all enabled and 200mW Tx power.


This are the same settings I've been running all along, and with pervious firmware prior to the 354 branch I didn't really have much problems, perhaps a few random drops out each month at most, now it has become a daily thing.

I have exactly the same setup and am having similar problems.

What did help was resetting the AC66U back to factory defaults. After doing that i get a slowdown approximately every 3-7 days.

I would use the non beta release, but there is a bug in the Mountain Lion Wireless driver on the Retina, which makes it not reconnect after waking from sleep.

I am just hoping that Asus fixes the drivers soon.
 
How to enable execution of commands:

modprobe -q iptable_mangle
modprobe -q xt_HL
iptables -t mangle -D PREROUTING -i wlan0 -p udp -j TTL --ttl-inc 1
iptables -t mangle -A PREROUTING -i wlan0 -p udp -j TTL --ttl-inc 1
Hi,

Simple solution: Make yourself comfortable with Merlin's User Scripts - in particular wiht the firewall-start one! :rolleyes:

With kind regard
Joe :cool:
 
I had the same slowdown problem, but by adjusting the wireless settings it is now fixed.
The setting that helped was: Multicast RATE (Mbps) . I have set it to "OFDM 9". Other settings that I use is Wireless Mode "Auto".
 
Any timeframe when we expect the next beta? Last I heard, last weekend but that has come and gone.
 
I think Merlin is waiting on an update from ASUS at the moment - to fix some of the core issues (Eth lag, wireless beta drivers etc).

There's still some background development going on to tidy other things up, but I'll defer to Merlin as to when that reaches 'critical mass' to warrant a new release.
I don't think we'll see any massive differences though until ASUS come up with the goods...

You can see the ongoing progress here;

https://github.com/RMerl/asuswrt-merlin/commits/master

I tend to compile from the source every few days out of casual QA more than anything else.
 
I think Merlin is waiting on an update from ASUS at the moment - to fix some of the core issues (Eth lag, wireless beta drivers etc).

There's still some background development going on to tidy other things up, but I'll defer to Merlin as to when that reaches 'critical mass' to warrant a new release.
I don't think we'll see any massive differences though until ASUS come up with the goods...

You can see the ongoing progress here;

https://github.com/RMerl/asuswrt-merlin/commits/master

I tend to compile from the source every few days out of casual QA more than anything else.

I spent four whole evenings in the past week tracking down and fixing bugs related to Beeline's tunneled Internet and Per IP traffic monitoring. That's what forced me to delay the release by a week as was mentioned in my last post on the subject. The traffic monitoring bugs should all be squashed now, at least I can no longer reproduce any of the inaccuracies.

I finalized the traffic monitoring debugging only Wednesday, so I need a few days to test everything together before I can compile 6 different firmwares and prepare an actual release. So, it should be in the coming days, once I can spare a few hours to work on this.
 
Mr. Merlin! Can you do support "patch-o-matic" in the next firmware? It is necessary to empower iptables.
To work commands:
modprobe -q iptable_mangle
modprobe -q xt_HL
iptables -t mangle -D PREROUTING -i eth0 -p udp -j TTL --ttl-inc 1
iptables -t mangle -A PREROUTING -i eth0 -p udp -j TTL --ttl-inc 1
This is very important :)
 
Last edited:
Mr. Merlin! Can you do support "patch-o-matic" in the next firmware? It is necessary to empower iptables.
To work commands:
modprobe -q iptable_mangle
modprobe -q xt_HL
iptables -t mangle -D PREROUTING -i eth0 -p udp -j TTL --ttl-inc 1
iptables -t mangle -A PREROUTING -i eth0 -p udp -j TTL --ttl-inc 1
This is very important :)

These two are already supported by the firmware. First one is built in, second one is available as a module.
 
Will this latest beta include fixed/working Broadcom drivers for the RT-N66U?

No, Asus hasn't released any update yet.
 
Sorry to have to ask this....but what exactly is wrong with the Broadcom driver on the N66U?

I think that it depends on your specific wireless interface cards. For me, I cannot even connect to the 5GHz. wireless on my router unless I set the channel to 20MHz. width, and that slows things down a bunch for file transfer. So I'm not using 5GHz. at this point, since 2.4GHz. now is faster than 5GHz.

Back on 26b now, where I can use my 5GHz. wireless at a reasonable speed. Hate to lose the Site Survey feature (from 29), but so it goes.
 
Last edited:
RMerlin if I want to go back to 26b do I have to reset and manually re-enter settings?
 
RMerlin if I want to go back to 26b do I have to reset and manually re-enter settings?

It's recommended, but not mandatory. Give it a try, and if you experience odd wireless behaviour, then reset to factory defaults.
 
After upgrade to 3.0.0.4.354.27 Beta 1 (particularly, I suspect, changes to webui code), I get the following message whenever I try to access N66U's webui through HTTPS from any of my iOS devices:

"A change has been made, causing disconnection to setting page.You may made the change in changing IP address, changing port number or disconnecting Wi-Fi to RT-N66U.Please re-connect Wi-Fi and use modified IP address and port number to access setting page of RT-N66U."

Clearing cache from web browsers or rebooting the router helps. Any subsequent firmware Beta versions (3.0.0.4.354.28 or .3.0.0.4.354.29) behave identically.

I believe I have not changed any settings since upgrading to this firmware revision.

What could I be doing wrong?
 
I had problems with our Android devices with this firmware.

They connect maybe 1-3 times to the router and work OK. (When outside I always disable Wifi on the smartphone to safe battery capacity, when at home I re-enable Wi-Fi again). So after some switching on/off cycles there will be no data-flow anymore.

The Android device shows connection to the router but there's simply no data transmitted between them. Once the router is resetted it works again.

I swichted back to 270.26 now and the problems are completely gone... even after numerous switch on/off cycles
 
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