[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[roundaway]

@john9527

Was able to grab the RT-AC-56U CFE v1.0.2.9 and edited the settings. Was able to use mtd-write. Funny thing. The nvram get bl_version is still 1.0.1.9 but the 18E3 "Tools", "Sysinfo" shows CFE 1.0.2.9

 

[john9527]

@john9527

Was able to grab the RT-AC-56U CFE v1.0.2.9 and edited the settings. Was able to use mtd-write. Funny thing. The nvram get bl_version is still 1.0.1.9 but the 18E3 "Tools", "Sysinfo" shows CFE 1.0.2.9

You need to do a factory reset to update the nvram....the tools page makes a call directly to the CFE.

EDIT: BTW....a saved config with the previous bootloader will now be invalid. You should reconfigure from scratch after a factory reset.

 

[jrmwvu04]

I loaded 19E2 directly over 19B4, and toggled power switch for a reboot. Worked fine. Wiped the nvram and toggled power again just to see what happened there, all normal after the fresh boot. Reconfigured, good to go on all fronts.

edit: my CFE is customized, if that makes any difference. I dumped the 1.0.2.5 that was factory installed, edited a few values, and replaced it.

 

[Pat57]

John,

No change for me with 19E2.

Below is a log after upgrading to 19E2, doing a reset and just entering SSID's to get the router to the main page. Log is just before rebooting. The reboot was not successful.

Back on 18E3.

https://www.dropbox.com/s/5lbng0bwazguo96/syslog_1.txt?dl=0

 

[john9527]

No change for me with 19E2.

Thanks for providing the system log! I can see the problem (or at least a symptom)...but I don't know what would cause it. Your system time is jumping all over the place.....between Sept 11 and Sept 12 and back. Are you doing anything special with your ntp servers?

 

[Pat57]

No. I had it set up to provide a local NTP server with 18E3. I don't know why it was jumping around so much after the update. I would assume it would reset once during the boot sequence (I am resetting with the top button while pushing the power button).

Again, really appreciate your support!

 

[SHAH]

how much tx power i can increase in this firmware?

 

[InkyRag]

@InkyRag - I need some help since I can't recreate it. Can you capture a syslog (upload to a file sharing site and post a link - or PM me the link)?

Sorry, I was out of commission for most of the weekend but am back now. I have a syslog for you that I took after a router reboot. The reboot took 2 minutes and 33 seconds. I will have it uploaded to dropbox and will pm the link to you shortly. Thanks.

Edit: Rebooting the an access point with the same firmware also took 2 minutes and 33 seconds. I remember that Tomato ARM had a similar problem a while back. Maybe related to the Tomato code that was incorporated in this build?

 

[M1ch43lk]

I upgraded from 18E3 to 19E2 and my router is now dead

What is the best procedure to get back to 18E3?

EDIT: Sorry forgot to mention I'm using RT-AC68U

 

[john9527]

Sorry, I was out of commission for most of the weekend but am back now. I have a syslog for you that I took after a router reboot. The reboot took 2 minutes and 33 seconds. I will have it uploaded to dropbox and will pm the link to you shortly. Thanks.

Edit: Rebooting the an access point with the same firmware also took 2 minutes and 33 seconds. I remember that Tomato ARM had a similar problem a while back. Maybe related to the Tomato code that was incorporated in this build?

Actually, everything looks good....

Sep 12 10:12:29 rc_service: httpd 550:notify_rc reboot

Sep 12 10:12:33 kernel: xhci_hcd 0000:00:0c.0: USB bus 1 deregistered
Dec 31 17:00:12 syslogd started: BusyBox v1.20.2 >> approx 4+12 sec until start of boot

Dec 31 17:00:52 dnsmasq-dhcp[543]: DHCPACK(br0) 192.168.110.50 00:1d:c9:21:d6:61 Ring-Doorbell
Sep 12 10:14:17 rc_service: ntp 685:notify_rc restart_upnp >> 52 sec before clock is set

Sep 12 10:14:25 crond[551]: time disparity of 2997613 minutes detected >> >> 8 more sec until end of boot

so boot = 4+12+52+8 = 1 min 16 sec (actually this is about right since you are not running many services). How are your measuring the boot time?

After this your Ring-Doorbell keeps requesting and being granted an IP address by the router. The router is doing everything right, it's the Doorbell that's generating repeated DHCP requests. If you haven't already, try assigning a fixed address for it.

 

[john9527]

I upgraded from 18E3 to 19E2 and my router is now dead

What is the best procedure to get back to 18E3?

EDIT: Sorry forgot to mention I'm using RT-AC68U

Please describe 'dead'...that doesn't tell much.

First thing to try is to do a factory reset. power off the router.....press and hold the WPS button on the side of the router and power back on.....keep holding the WPS button until the power led starts a fast blink. Release the WPS button and the router should reboot.

If that doesn't recover it, you'll need to use the ASUS Firmware Recover utility.

 

[InkyRag]

Actually, everything looks good....


so boot = 4+12+52+8 = 1 min 16 sec (actually this is about right since you are not running many services). How are your measuring the boot time?

After this your Ring-Doorbell keeps requesting and being granted an IP address by the router. The router is doing everything right, it's the Doorbell that's generating repeated DHCP requests. If you haven't already, try assigning a fixed address for it.

I was measuring boot time based on the web interface telling me that the reboot had completed.

The ring doorbell is a known issue. After I reboot the router and access point it does this until I reset it and reconnect it. It is on a static IP. Ring tells me it is normal, which it is not.

 

[john9527]

I was measuring boot time based on the web interface telling me that the reboot had completed.

All that does it load a timer to the browser and counts down (and is set at a high enough value to cover folks that run a 'typical' mix of services). It doesn't actually get status for the boot process. For me (running a lot of extras) it can actually come back a few seconds before the reboot is actually complete. I've thought about trying to dynamically set the boot timer based on what services are being used, but it's never been a high enough priority.

 

[john9527]

Re load problems....for the AC56 and AC68 routers, please verify that your CFE bootloader is at least at 1.0.2.x before loading V19 (check on the Tools>Sysinfo page) . If your bootloader is not at the correct level, you may update it by first loading the ASUS update code in the ASUS-OEM-CFE folder in the same directory with the fork code.

I still cannot recreate any problem, so am guessing here. Since the upgrade to a 64M rootfs for the ARM routers, the code still was still able to be loaded and run on the older bootloaders since it was small enough. With the continuing code growth, it may still be able to load without triggering the check, but may fail on boot without the updated CFE.

 

[M1ch43lk]

Please describe 'dead'...that doesn't tell much.

If that doesn't recover it, you'll need to use the ASUS Firmware Recover utility.

Thanks, I managed to get back to 18E3 using the "ASUS Firmware Recover utility"

Dead = No Wifi, No DHCP, Not answering to ping,

I tried the upgrade from 18E3 to 19E2 a few times.

By first just running it, later on reset settings, upgrade and so on...
but unfortunately it always ends up with the router in an unstable/dead state. Somewhere after 28%-30% I see the LEDs blink a few times and after that nothing more happens.

RT-AC68U, bootloader version is 1.0.2.0

Anything more you want me to check?

 

[john9527]

Anything more you want me to check?

If you are willing, could you try the V19B4 release (that would help to narrow down the patch that could be causing a problem).

 

[Santiago C]

@john9527 first, kudos for your hardwork! I have been using Merlin's fw on my AC68U for over a year now and just recently switched to your fork, which seems to be better so far with the following caveat:

I have 2 USB drives attached (one on each port) and for some reason while using your fork it seems one of those disks is detected twice as a device. It will appear as something like "sdb" and mount to the expected mountpoint under its label, only to disappear and reappear as "sda" and mount as "{label}(1)".

Since that disk contains the entware installation, the post-mount script fails and nothing gets started.

This is happening coming from a 100% clean install of V18E3 and now after updating to V19E2 (without clearing the nvram)

I've tried using a fstab file which the UUID and the specific mountpoint that I wanted, but since the device gets detected twice, that mountpoint is used on first detection only (I've resorted to use /dev/sda2 in the fstab file, knowing it is not futureproof).

Here is the syslog from a recent bootup where you might be able to see what happens, let me know if there is anything I can do to help get that sorted out! http://pastebin.com/QarM8ZxM


Thanks!!!

 

[john9527]

It will appear as something like "sdb" and mount to the expected mountpoint under its label, only to disappear and reappear as "sda" and mount as "{label}(1)".

On the Wireless>Professional page for 2.4GHz, disable the reduce USB3 interference setting.

EDIT: Oh, and thanks for verifying that someone besides me can update from 18E3 to 19E2 without problems

 

[Santiago C]

On the Wireless>Professional page for 2.4GHz, disable the reduce USB3 interference setting.

Care to tell me the drawbacks of that setting disabled? I have no clue what it does...

EDIT: Oh, and thanks for verifying that someone besides me can update from 18E3 to 19E2 without problems

Just updated less than an hour ago, so still keeping my fingers crossed! Updated remotely over SSH via VPN, bold move...

 

[john9527]

Care to tell me the drawbacks of that setting disabled? I have no clue what it does...

When enabled, that forces the USB3 port to run at USB2 speeds. The higher USB3 speeds can in theory interfere with the 2.4 GHz band. In the process of doing that, it first brings up the port as USB3, then USB2. When it switches is what causes the change in mount points.

I personally haven't seen any difference. As long as you are using a good quality USB3 cable (properly shielded) or using a USB stick you should be fine.