Asuswrt-Merlin 3.0.0.4.354.28 Beta 1

[RMerlin]

Merlin have mentioned .364 is in works, but is it available to download and try? Usually I do this without hesitation. For example, 345, 352 were much better for me than 270. At this time i'm using 354.27, but I recently found, that my samsung ES8000 TV is still dropping connection on 5 Ghz network... Want to try new firmaware, let it be beta, no problem at all.

No binary build available yet. I only fixed the last merge issues late last night, and there is still my own internal testing to do before I even merge it in the master repo. Plus I want to give Asus more time to possibly release fixed drivers before making a new release myself.

The 5 GHz issue won't be fixed until Asus releases new wireless drivers.

 

[Pericynthion]

Well .364 is compiled and up and running.
So far nothing to report (which I guess is a good thing) - I'll watch it carefully over the next 24hrs.

 

[Pericynthion]

Minor comment - I saw this in the log when running the QIS wizard with .364;

May 1 10:39:50 rc_service: httpd 695:notify_rc start_autodet
May 1 10:39:50 kernel: autodet uses obsolete (PF_INET,SOCK_PACKET)

Nothing broken, probably just related to a library update.

 

[RMerlin]

Minor comment - I saw this in the log when running the QIS wizard with .364;

May 1 10:39:50 rc_service: httpd 695:notify_rc start_autodet
May 1 10:39:50 kernel: autodet uses obsolete (PF_INET,SOCK_PACKET)

Nothing broken, probably just related to a library update.

I've started doing some minor cleanups here and there since I'm waiting for updated drivers before I can make a new release. Anything kernel-related is something I'd rather not mess to much for now (truth be told, it's a bit beyond my knowledge skills too), but other areas are seeing some tidying up. For instance, the firmware will no longer start to run miniupnpd right at boot time - no point since it needs a working WAN interface to work. It already gets (re)started when WAN comes up. That will save a few error entries in the log.

Another recent change is dnsmasq, which was also being started when it should only be restarted IF it was already running. That was causing the firmware to try to run it twice at the same time (first through a restart, and then through a direct start).

On an unrelated subject, I tried once more to downgrade the drivers to the 5.100 SDK version. Too many changes in the FW related to this, so it's not realistically doable unless I would also downgrade the whole kernel tree to the 270 state, which would also force me to also downgrade the RT-AC66U components.

That was the intent behind the 364 test branch: make a Frankenbuild using newer FW code and older wireless drivers. Since that's not realistic, focus will be moved back to the 354 code for now. No use in upgrading the code to 364, since when Asus releases a new driver it will probably also come with an even newer firmware. And I'd prefer to hold any new release until the wireless issue can be resolved.

I'll leave 364 on Git for now for experimental purposes (might also save me time when comes the time to merge with an even newer version).

 

[Pericynthion]

Ok - thanks. I've just recompiled that master from the latest source, so I'm back on the 354 for now.
As you say, probably worth leaving 364 as a Frankenbuild for all that crazy , after-dark stuff ;-)

 

[RMerlin]

Yes, in one row but further down it shows the correct VLANs. maybe they are "mappable" in some way.

admin@router:/tmp/var# robocfg show
Switch: enabled gigabit
Port 0:  100FD enabled stp: none vlan: 2 jumbo: off mac: 00:00:00:00:00:00
Port 1: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 2:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 3:   DOWN enabled stp: none vlan: 41815 jumbo: off mac: 00:00:00:00:00:00
Port 4:  100FD enabled stp: none vlan: 33613 jumbo: off mac: 00:00:00:00:00:00
Port 8: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
VLANs: BCM53115 enabled mac_check mac_hash
   1: vlan1: 1 2 8t
   2: vlan2: 0 8u
 845: vlan845: 0t 4
 855: vlan855: 0t 3

Found it. The switch register is 16-bit. 12 first bits are the actual ID, the 13th bit is unused by the firmware, and the 3 remaining bits are the priority. robocfg simply dumps the 16-bit vlan register.

I modified the webui to use a 12-bit mask when displaying the value, so the actual VLAN ID gets reported.

 

[HeadBanger]

Hi Merlin. Happened to find your forum posts by accident and after reading here decided to give your firmware a go on my newish RTAC66U and very impressed so far - thank you!

On the stock ASUS firmware I had to set Wi-Fi to N only in order for my Squeezeboxes to connect. Once upgrading to your version none of them would connect - they could see the ASUS but would not connect. I was about to give up and roll back to the ASUS version and decided to try setting wireless mode back to Auto and hey presto - everything connected again. Not sure if your firmware corrects an ASUS bug here but I'm also not sure why they would now refuse to connect when set to N only?

A small request on the WiFi scheduler - would it be possible to add a function to allow Friday to be included in the weekend and Sunday not? In our house we are up later on Friday and Saturday night so it would be useful to set these two independently of the other days.

Oh, and the stealth mode is nice!

 

[BOFH]

Hello Folks,

I have seen on my logs some errors:

May 2 09:49:34 routeur kernel: nf_ct_ras: decoding error: out of range
May 2 09:50:26 routeur kernel: nf_ct_ras: decoding error: out of range


grep error router.log | wc -l
79

Any idea about this?

 

[sherion]

1. Enabling PPTP VPN server leads to the double and concurrent launch of the 'firewall-start' script during the boot.
2. Vanished 'recent' module for iptables. Is there hope for a comeback?

 

[RMerlin]

Hello Folks,

I have seen on my logs some errors:

May 2 09:49:34 routeur kernel: nf_ct_ras: decoding error: out of range
May 2 09:50:26 routeur kernel: nf_ct_ras: decoding error: out of range


grep error router.log | wc -l
79

Any idea about this?

Ignore it. It's debugging output that was left behind in the Netfilter SIP helper. The message was removed in latter versions of the Linux kernel.

 

[RMerlin]

On the stock ASUS firmware I had to set Wi-Fi to N only in order for my Squeezeboxes to connect. Once upgrading to your version none of them would connect - they could see the ASUS but would not connect. I was about to give up and roll back to the ASUS version and decided to try setting wireless mode back to Auto and hey presto - everything connected again. Not sure if your firmware corrects an ASUS bug here but I'm also not sure why they would now refuse to connect when set to N only?

No idea. The wireless driver used in this beta is the same as in Asus's 354 beta. Could be a bug in that new driver - try rolling back to the latest stable version (270.26b).

A small request on the WiFi scheduler - would it be possible to add a function to allow Friday to be included in the weekend and Sunday not? In our house we are up later on Friday and Saturday night so it would be useful to set these two independently of the other days.

If I did, then people who are on a more regular weekday schedule would complain in turn Sorry.

 

[RMerlin]

1. Enabling PPTP VPN server leads to the double and concurrent launch of the 'firewall-start' script during the boot.
2. Vanished 'recent' module for iptables. Is there hope for a comeback?

Odd - could be a timing issue. I will have to see if I can reproduce it.

Did you try inserting the recent module? I didn't voluntarily remove any module from the kernel recently, so it should still be there if it was before.

 

[janosek]

Much Improved OpenVPN, VOIP and selective routing experiences with .354.28

Hello,

I just wanted to communicate that the timing issues with selective routing seem to have been resolved with .354.28 and the new openvpn-event user script. Its fantastic. I haven't had a single issue after rebooting several times. Thanks RMerlin!

 

[koncelm]

regional settings problem

i'm trying to change regional setting to XX

regulation_domain=XX
regulation_domain_5G=XX

changes are made ok, i see all the allowed channels in channel list in wireless settings, but the radio still runs on 36 .

the same problém is on the original 354 and 270.26b

 

[HeadBanger]

No idea. The wireless driver used in this beta is the same as in Asus's 354 beta. Could be a bug in that new driver - try rolling back to the latest stable version (270.26b).

I was already on ASUS's 354 beta but no need to roll back - it works! I was just pointing out what I had to do to get it to work changing from ASUS's 354 to your 354.28.

If I did, then people who are on a more regular weekday schedule would complain in turn Sorry.

I meant as an option and not instead of. I would think that a larger proportion of users work Mon-Fri and this would be of added value to them as they are not going to be up late Sunday if they have work on Monday. No biggie just a nice to have!

 

[FireWire76]

:

A small request on the WiFi scheduler - would it be possible to add a function to allow Friday to be included in the weekend and Sunday not? In our house we are up later on Friday and Saturday night so it would be useful to set these two independently of the other days.

If I did, then people who are on a more regular weekday schedule would complain in turn Sorry.

Isn´t it possible in all schedulers to add all days, and then check the days you want to include in the specific time schedule. A suggestion would be that if one day is checked in any of the schedules, then that day would be grayed out in the other?
Would be nice if this was possible. Hope I explained clearly else tell me and I can post an image to explain it better.

 

[dodava]

Odd - could be a timing issue. I will have to see if I can reproduce it.

Did you try inserting the recent module? I didn't voluntarily remove any module from the kernel recently, so it should still be there if it was before.

The new SSH brute force protection option uses the netfilter recent module, so it is now compiled as part of the kernel versus as a kernel module.

 

[DaveMishSr]

I was already on ASUS's 354 beta but no need to roll back - it works! I was just pointing out what I had to do to get it to work changing from ASUS's 354 to your 354.28.

Merlin's point was that Beta software is inherently unstable. Your workaround may cause other issues or it may work flawlessly forever.

I meant as an option and not instead of. I would think that a larger proportion of users work Mon-Fri and this would be of added value to them as they are not going to be up late Sunday if they have work on Monday. No biggie just a nice to have!

The problem is that it usually isn't that simple. There is no way to tell how that "option", even if it's possible, may affect overall stability. Merlin does this in his spare time so "nice to haves" are almost always DOA. No harm in asking though.

 

[BobMCT]

File error msg with .28-beta

Hi! Love the Merlin builds on my N66U router. Just downloaded and unzipped the 354.28-beta version and tried to upload it to the router. I only get the error window "invalid file format". Downloaded again, checked for zip errors, unzipped then reference the trx file in the firmware upgrade section and again only receive the invalid file message.

Any ideas/thoughts?

btw - I am currently running .27-beta so I know uploading firmware works fine otherwise.

Thanks

 

[RMerlin]

Hi! Love the Merlin builds on my N66U router. Just downloaded and unzipped the 354.28-beta version and tried to upload it to the router. I only get the error window "invalid file format". Downloaded again, checked for zip errors, unzipped then reference the trx file in the firmware upgrade section and again only receive the invalid file message.

Any ideas/thoughts?

btw - I am currently running .27-beta so I know uploading firmware works fine otherwise.

Thanks

Make sure you are on the Firmware Upload page, not the Settings upload page (I've seen people make that attention mistake in the past).