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

[Ford Prefect]

@Ford Prefect/@cofeytm - If you click on the exclamation point it should bring up a pop-up telling you what it thinks is wrong.

I've been playing around with options that would bring up the ! warnings and so far haven't run across anything abnormal.

..my mark did disappear when I activated DUAL-WAN.

All I can remember is that I enabled samba service (non guest) some time/weeks ago
and the mark appeared. I remember that I double-checked the WAN-side access modes to be switched off, as the mark made me nervous.
Upon enabling DUAL-WAN, two days ago, the mark was gone and smaba+ftp service were still running with guest access disabled (still).

I now tried to reproduce the issue by deactivating DUAL-WAN and the ASUS went completely upside down....my WLAN clients ended up with IPs from my router on my second WAN ...had to switch it off manually...now I cannot reproduce the issue....the mark only appears when guest access is on for samba or ftp.

...I am very sorry for causing such a confusion on a minor bug, really.

 

[cofetym]

Yep! I noticed that and went to where it wanted me to go. Didn't make any changes and the exclamation mark decided to disappear

 

[krick]

I don't know if this is specific to this build or not, but I was wondering if anyone else was seeing this kind of thing in their logs...


Jan 17 10:35:20 kernel: br0: received packet on eth2 with own address as source address
Jan 17 15:43:31 kernel: br0: received packet on eth2 with own address as source address
Jan 17 15:44:16 kernel: br0: received packet on eth1 with own address as source address
Jan 17 15:44:18 kernel: br0: received packet on eth1 with own address as source address

 

[twitchyzero]

just updated to 374.43 06E Merlin Fork from 374.42 Merlin

So my understanding is Fork takes all the goodies from the latest Merlin build but still allows you to adjust signal >80mW?

Immediate problem: it no longer recognize my 5TB HDD via USB 3 or 2 ports.

Reboot doesn't help

Any settings I should look at before reset?

I'm also confused at Merlin's instructions about upgrading/installing

If something looks weird, don't waste too much time: save your settings, reset to factory default, reconfigure the basics, and see if the issue is resolved. If not, you can always restore your saved settings, and do some more advanced troubleshooting.
It is NOT recommended to restore settings saved under a different firmware version. It might work, but there is no guarantee.

I don't quite understand the last point. What's the point of saving settings when you're upgrading when it's recommended not to restore it onto a diff FW? Do you guys always have to manually change the settings everytime you upgrade FW? Seems cumbersome?

 

[KGB7]

I don't quite understand the last point.

A reminder for those that continue to ignore what has been said a hundred times.

 

[john9527]

Yep! I noticed that and went to where it wanted me to go. Didn't make any changes and the exclamation mark decided to disappear

You had said the warning mark appeared after enabling telnet....just for interest, where did it send you to resolve the warning?

 

[john9527]

I don't know if this is specific to this build or not, but I was wondering if anyone else was seeing this kind of thing in their logs...


Jan 17 10:35:20 kernel: br0: received packet on eth2 with own address as source address
Jan 17 15:43:31 kernel: br0: received packet on eth2 with own address as source address
Jan 17 15:44:16 kernel: br0: received packet on eth1 with own address as source address
Jan 17 15:44:18 kernel: br0: received packet on eth1 with own address as source address

eth1 = 2.3GHz wifi, eth2=5Ghz wifi

I believe these have been reported to be seen if you have the same SSID for both 2.4 and 5GHz radios

or

if you have a configuration with an access point that uses the same SSIDs as the main router.

They are generated as you are roaming and switching between radios. If you fall into one of these cases, it's generally recommended you use different SSIDs for 2.4/5Ghz and/or the access point.

One other thing I have seen generate the messages are some of the AC wireless drivers. Mine has an option under 'Mixed mode protection' called 'CTS-to-self'....and indeed, I see this entry about 75% of the time when that client connects.

 

[john9527]

just updated to 374.43 06E Merlin Fork from 374.42 Merlin

So my understanding is Fork takes all the goodies from the latest Merlin build but still allows you to adjust signal >80mW?

Not quite....it takes the 374.43 level from Merlin and creates a maintenance stream for it. I try to keep it up to date with major security updates, any key fixes and try to respond to simple user requests for new functions/fixes. It doesn't attempt to chase the new functions in the latest releases. You are correct, in that this was the last level that gave the ability to make significant changes in the power level.

Immediate problem: it no longer recognize my 5TB HDD via USB 3 or 2 ports.

Reboot doesn't help

Any settings I should look at before reset?

I'm not aware of any changes that were made in the USB code between .42 and .43 and I haven't made changes there. Same thing with the file system drivers, so I don't have a quick answer as to what could be the problem.

The usb connection sequence is logged in the syslog (do a search for usb)...that may help to pinpoint what's going wrong.

I'm also confused at Merlin's instructions about upgrading/installing


I don't quite understand the last point. What's the point of saving settings when you're upgrading when it's recommended not to restore it onto a diff FW? Do you guys always have to manually change the settings everytime you upgrade FW? Seems cumbersome?

The save setting in the gui not only saves the 'user' parameters from nvram, but some low level parameters which you don't see and which can be unique to the firmware (particularly with respect to the wireless). Someone once made the analogy that it would be like doing an update to your operating system, then restoring your last backup prior to the update. So it's useful in case of some type of crash or if you want to experiment with different settings but be able to get back to a known good setup.

To get around this, I've written a little utility that only saves/restores the user settings. You can find it in the wiki....

https://github.com/RMerl/asuswrt-me...-I-restore-my-settings-to-a-different-router?

 

[RMerlin]

I don't quite understand the last point. What's the point of saving settings when you're upgrading when it's recommended not to restore it onto a diff FW? Do you guys always have to manually change the settings everytime you upgrade FW? Seems cumbersome?

Not every time we upgrade. Some firmware upgrades will do some low-level changes that will require a factory default reset - some don't.

Saving settings makes sense in case an accident locks you out of your router, or causes your router to lose its configuration. In such a case, you'll want to be able to restore a backup of your settings.

 

[twitchyzero]

I'm not aware of any changes that were made in the USB code between .42 and .43 and I haven't made changes there. Same thing with the file system drivers, so I don't have a quick answer as to what could be the problem.

The usb connection sequence is logged in the syslog (do a search for usb)...that may help to pinpoint what's going wrong.

https://github.com/RMerl/asuswrt-me...-I-restore-my-settings-to-a-different-router?

thanks keep up the great work

here's the log:

Spoiler

Jan 17 21:48:52 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 6
Jan 17 21:48:53 kernel: usb 2-2: device descriptor read/64, error -71
Jan 17 21:48:53 kernel: usb 2-2: device descriptor read/64, error -71
Jan 17 21:48:53 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 7
Jan 17 21:48:53 kernel: usb 2-2: device descriptor read/64, error -71
Jan 17 21:48:53 kernel: usb 2-2: device descriptor read/64, error -71
Jan 17 21:48:54 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 8
Jan 17 21:48:54 kernel: usb 2-2: device not accepting address 8, error -71
Jan 17 21:48:54 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 9
Jan 17 21:48:55 kernel: usb 2-2: device not accepting address 9, error -71
Jan 17 21:48:55 kernel: hub 2-0:1.0: unable to enumerate USB device on port 2
Jan 17 21:48:55 kernel: usb 3-2: new full speed USB device using ohci_hcd and address 6
Jan 17 21:48:55 kernel: usb 3-2: device descriptor read/64, error -62
Jan 17 21:48:55 kernel: usb 3-2: device descriptor read/64, error -62
Jan 17 21:48:56 kernel: usb 3-2: new full speed USB device using ohci_hcd and address 7
Jan 17 21:48:56 kernel: usb 3-2: device descriptor read/64, error -62
Jan 17 21:48:56 kernel: usb 3-2: device descriptor read/64, error -62
Jan 17 21:48:56 kernel: usb 3-2: new full speed USB device using ohci_hcd and address 8
Jan 17 21:48:57 kernel: usb 3-2: device not accepting address 8, error -62
Jan 17 21:48:57 kernel: usb 3-2: new full speed USB device using ohci_hcd and address 9
Jan 17 21:48:57 kernel: usb 3-2: device not accepting address 9, error -62
Jan 17 21:48:57 kernel: hub 3-0:1.0: unable to enumerate USB device on port 2

I also see this line repeatedly...should I be concerned?

Problem loading /mnt/sda1/tomato_cstats_ac220b24fc08.gz. Still trying..

I'll have a look-see into the utility.

Not every time we upgrade. Some firmware upgrades will do some low-level changes that will require a factory default reset - some don't.

thanks for all the hardwork and quick reply. So sticking to your rule of if it's in the same family (374.01 to 374.05 for example) then it's not needed, but if different family (374.05 to 376.02 for example) requires reset. That golden rule minimizes potential issues?

 

[lex131]

Limited download speeds

Hello John,

I'm new on this forum and just installed your fork last night over the Asus original firmware.

I live in Romania where we have fiber to the home and my subscription is of 500Mb/s.

I reached those speeds using direct connection but not with my Asus AC68U.

I had Asus FW xxx.3626, than updated to xxx.3873 - and still the same maximum speeds:
Online Test speeds: 280Mb/s
Torrent dl speeds: 280Mb/s

I then switched to your fork, 3.0.0.4.374.43_2-06Ej9527, did a factory reset 10 seconds reset button.

And now i have:
Online Test speeds: 493Mb/s
Torrent dl speeds: 176Mb/s

No matter what I try, those numbers don't change.

We're not talking about wireless, just wired network, with a pc i7, 16GB ram.

It is a pppoe connection and I didn't change anything besides ssid, passwords and some DHCP fixed ip allocations - that's it, the rest is as you have set it.

nvram get bl_version
1.0.2.0

nvram get clkfreq
800,666

These are the only 2 commands I know just thought you could use more info.

Any ideas?

Thank you!

 

[lex131]

Solved it

With the help of a fellow country man, who directed me to this post:

http://forums.smallnetbuilder.com/showpost.php?p=149060&postcount=12

Now it's solved, just downloaded with 60MB/s using uTorrent.

 

[cofetym]

You had said the warning mark appeared after enabling telnet....just for interest, where did it send you to resolve the warning?

If I remember correctly, "The Quick Internet Setting"!

 

[RMerlin]

thanks for all the hardwork and quick reply. So sticking to your rule of if it's in the same family (374.01 to 374.05 for example) then it's not needed, but if different family (374.05 to 376.02 for example) requires reset. That golden rule minimizes potential issues?

The rule is more to read the changelog and the release thread I create here, as I will mention when a factory default is recommended, mandatory, or not needed at all. Wireless updates aren't always matched by a major version bump for instance.

 

[john9527]

thanks keep up the great work

here's the log:

Spoiler

Jan 17 21:48:52 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 6
Jan 17 21:48:53 kernel: usb 2-2: device descriptor read/64, error -71
Jan 17 21:48:53 kernel: usb 2-2: device descriptor read/64, error -71
Jan 17 21:48:53 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 7
Jan 17 21:48:53 kernel: usb 2-2: device descriptor read/64, error -71
Jan 17 21:48:53 kernel: usb 2-2: device descriptor read/64, error -71
Jan 17 21:48:54 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 8
Jan 17 21:48:54 kernel: usb 2-2: device not accepting address 8, error -71
Jan 17 21:48:54 kernel: usb 2-2: new high speed USB device using ehci_hcd and address 9
Jan 17 21:48:55 kernel: usb 2-2: device not accepting address 9, error -71
Jan 17 21:48:55 kernel: hub 2-0:1.0: unable to enumerate USB device on port 2
Jan 17 21:48:55 kernel: usb 3-2: new full speed USB device using ohci_hcd and address 6
Jan 17 21:48:55 kernel: usb 3-2: device descriptor read/64, error -62
Jan 17 21:48:55 kernel: usb 3-2: device descriptor read/64, error -62
Jan 17 21:48:56 kernel: usb 3-2: new full speed USB device using ohci_hcd and address 7
Jan 17 21:48:56 kernel: usb 3-2: device descriptor read/64, error -62
Jan 17 21:48:56 kernel: usb 3-2: device descriptor read/64, error -62
Jan 17 21:48:56 kernel: usb 3-2: new full speed USB device using ohci_hcd and address 8
Jan 17 21:48:57 kernel: usb 3-2: device not accepting address 8, error -62
Jan 17 21:48:57 kernel: usb 3-2: new full speed USB device using ohci_hcd and address 9
Jan 17 21:48:57 kernel: usb 3-2: device not accepting address 9, error -62
Jan 17 21:48:57 kernel: hub 3-0:1.0: unable to enumerate USB device on port 2

That syslog looks like the USB drive just isn't responding. A couple of things to try if you haven't already....

- Power cycle the USB drive. I'm seen some drives that get hung up and just won't free up without a power cycle.
- You didn't say how the drive was formatted, but if you can temporarily attach the drive to a PC and run chkdsk or fsck
- Try replugging the usb cable at the drive

I also see this line repeatedly...should I be concerned?

Problem loading /mnt/sda1/tomato_cstats_ac220b24fc08.gz. Still trying..

That file is used for the IPTraffic history and it looks like you placed it on the usb drive (sda1 refers to the usb drive). Since it can't see the drive, it can't get the file. Will likely go away after we get the drive fixed.

I'll have a look-see into the utility.


thanks for all the hardwork and quick reply. So sticking to your rule of if it's in the same family (374.01 to 374.05 for example) then it's not needed, but if different family (374.05 to 376.02 for example) requires reset. That golden rule minimizes potential issues?

Merlin gave the best answer here....it really depends on the code changes.

 

[john9527]

With the help of a fellow country man, who directed me to this post:

http://forums.smallnetbuilder.com/showpost.php?p=149060&postcount=12

Now it's solved, just downloaded with 60MB/s using uTorrent.

Welcome to the forum! And congratulations on tracking down the solution!

Just to summarize for others....

Downloads were fine at 493MB/s on a 500MB/s service , but torrent downloads were running at less than half of the measured download speed.

The solution:
The slowdown was caused by the Micro Transport Protocol (uTP) employed by uTorrent.
After disabling the option (Options -> Preferences -> BitTorrent -> Enable bandwidth management [uTP]), the download speed is almost flat at 500Mbps.

My best guess....somehow the uTP protocol isn't able to take advantage of the Hardware (NAT) acceleration needed to support these high speeds.

Will file this one away for future reference. Thanks for following up.

 

[twitchyzero]

That syslog looks like the USB drive just isn't responding. A couple of things to try if you haven't already....

a simple reset did the trick, thanks.

Only to be followed up by another question:

I used to be able to access the HDD from my PC on the same network. Now under Computer > Network I can only see my router under Media Device (media server) and Network Infrastrcuture (admin UI page), but it's not under Computer section where I can actually go into the drive.

Samba is on, guest login off, NFS exports off, FTP off (I tried turning this on but didn't make a difference), anon login off. I believe HDD format is NTFS but shouldn't matter because it worked before flashing to Fork.

 

[jim769]

I know firmware developers hate this question but any idea on a V7 final release ?

Love this firmware as it has brought my N66U back to life..

 

[john9527]

I know firmware developers hate this question but any idea on a V7 final release ?

Love this firmware as it has brought my N66U back to life..

I had hoped to have it out already but have a tale of woe to tell....I ran into the first major clash between Merlin's latest code and the fork.

I regularly do updates to the 'master' branch to get Merlin's latest commits and let me occasionally play with something on the his latest release. The fork is set up as a different branch. As best I can tell, there are some files that were marked as 'untracked' when they really should have been tracked...they got updated in my fork, and I was no longer able to compile the fork. I struggled for quite a while trying to get things straightened out unsuccessfully (I'm far from a git expert).

Luckily, I never pushed the 'master' updates to github, so I just finished rebuilding my local repo from github and reconstructing the V7 code. I'm running through my testing and 24+ hours running now, so I should have it out in the next couple of days. Whew!

But, maybe something good came out of all this. Not sure why, but the gui seems to have a new 'snap' to it and feels a lot more responsive than it had been.

 

[jim769]

Thanks for the reply John. I for one will be looking for the new V7 update, never have been a fan of beta versions always looking for the stable final release.