What's new

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

  • 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!


Actually, this works fine on Google Chrome and IE browsers on my desktop and laptop.

On my iPhone Safari browser, it just doesn't want to finish loading correctly, and then keeps trying to reload.

This is after I did:
Save Http Certificate to No, Reboot.
Save Http Certificate to Yes, Reboot.

This is a bummer if I can't access it via iPhone Safari browser.
 
Last edited:
@followmsi - Argh......without getting too much into the weeds....

One of the things I finally tracked down and fixed was the problem of a USB drive being mounted with a '(1)' appended to the mount point. If there was a minidlna directory on the usb drive, minidlna would create a phantom mount during the umount.

With that fixed, I think you exposed another ASUS bug. That is, if you manually delete the .minidlna directory on the USB drive, the minidlna directory will be moved to the default /var/cache/minidlna directory and get stuck there. I'm working on a fix for this case.

In the meantime, try this

service stop_dms
mkdir -p /tmp/mnt/path-to-your-media-dir/.minidlna (remake the path where it was)
mv /var/cache/minidlna/* /tmp/mnt/path-to-your-media-dir/.minidlna
rm -rf /var/cache/minidlna
service start_dms

Once it's back, it should stay put....
 
Actually, this works fine on Google Chrome and IE browsers on my desktop and laptop.

On my iPhone Safari browser, it just doesn't want to finish loading correctly, and then keeps trying to reload.
Safari has been problematic....even on the latest Merlin builds.
 
Does it have to do with the certificate, or https access?
I never had issues accessing via safari before this build.
I am not sure if it's iOS problem or browser problem, which has problem specific to HTTPS. I set my iPad to accept router's self-signed certificate(in Google Chrome if I remember correctly), but still there was problem accessing through HTTPS where the page will just be white/blank. HTTP is fine, as well as HTTPS for other browsers.
 
Does it have to do with the certificate, or https access?
I never had issues accessing via safari before this build.
What was the previous build before when it was working (I'm assuming you mean this build is 24E3).
If it was working on 24E2, the only change was the new cert gen.
If it was working on 23E4, the other major change was the inclusion of the OuiDb, but that should affect both http/https

What happens if you try and access it via
https://router.asus.com:8443
instead?

BTW here is a previously reported http authentication problem that apparently was never fixed on Safari......starting w/Safari 5.1 :eek:
https://www.snbforums.com/threads/f...lts-releases-v24e3.18914/page-187#post-255806
 
@followmsi - Argh......without getting too much into the weeds....

One of the things I finally tracked down and fixed was the problem of a USB drive being mounted with a '(1)' appended to the mount point. If there was a minidlna directory on the usb drive, minidlna would create a phantom mount during the umount.

With that fixed, I think you exposed another ASUS bug. That is, if you manually delete the .minidlna directory on the USB drive, the minidlna directory will be moved to the default /var/cache/minidlna directory and get stuck there. I'm working on a fix for this case.

In the meantime, try this

service stop_dms
mkdir -p /tmp/mnt/path-to-your-media-dir/.minidlna (remake the path where it was)
mv /var/cache/minidlna/* /tmp/mnt/path-to-your-media-dir/.minidlna
rm -rf /var/cache/minidlna
service start_dms

Once it's back, it should stay put....

It does not help ...

The minidlna will create a new folder in /var/cache/minidlna and starts scanning from scratch.

Have changed the nvram value .. for testing.


admin@RT-AC68U:/tmp/var/cache# nvram show | grep mini
size: 57741 bytes (7795 left)
dms_dbcwd=/tmp/mnt/sda1/.minidlna
dms_dbdir=/tmp/mnt/sda1/.minidlna

service stop_dms
service start_dms

admin@RT-AC68U:/tmp/var/cache# nvram show | grep mini
dms_dbcwd=/var/cache/minidlna
dms_dbdir=/tmp/mnt/sda1/.minidlna

And it's scanning again ..

admin@RT-AC68U:/tmp/var/cache/minidlna# ll
drwxr-x--- 3 admin root 60 Apr 24 08:54 art_cache/
-rw-r----- 1 admin root 10162176 Apr 24 08:58 files.db
-rw-r----- 1 admin root 1341 Apr 24 08:57 minidlna.log
-rw-r----- 1 admin root 0 Apr 24 08:54 scantag

Seems to be a bug ..

Pls let me know if I can test everything else for you ...

Thanks
 
What was the previous build before when it was working (I'm assuming you mean this build is 24E3).
If it was working on 24E2, the only change was the new cert gen.
If it was working on 23E4, the other major change was the inclusion of the OuiDb, but that should affect both http/https

What happens if you try and access it via
https://router.asus.com:8443
instead?

BTW here is a previously reported http authentication problem that apparently was never fixed on Safari......starting w/Safari 5.1 :eek:
https://www.snbforums.com/threads/f...lts-releases-v24e3.18914/page-187#post-255806

I should clarify, I had not tried to access via https until 24e3.
On 24e2 and before, I only used http to access the router page via safari.
This morning I switched it back to http, and can access the router page just fine on Safari with 24e3.
 
@mistercoffee1 - Did you try with the DNS name? I have a specific reason for asking.
https://router.asus.com:8443/

I gave this a try just now, using https access.

"Safari cannot open the page. The error was: "WebKit encountered an internal error"."

I tried refreshing the page, and it loaded halfway, then tried to reload by itself. "A problem occurred with this webpage so it was reloaded". It proceeded to reload by itself a third time.

The third time, it loaded, but is slow to respond.
 
BTW here is a previously reported http authentication problem that apparently was never fixed on Safari......starting w/Safari 5.1 :eek:
https://www.snbforums.com/threads/f...lts-releases-v24e3.18914/page-187#post-255806

That behavior is still present in current versions of Safari, both desktop and mobile.
@followmsiOne of the things I finally tracked down and fixed was the problem of a USB drive being mounted with a '(1)' appended to the mount point. If there was a minidlna directory on the usb drive, minidlna would create a phantom mount during the umount.

Is whatever causes the (1) situation fixed by putting a label on the drive? I was encountering some various weirdness with my USB key a long time ago, and a suggestion I found was labeling the drive with tune2fs, which seemed like a decent idea and did solve my issues.
 
That behavior is still present in current versions of Safari, both desktop and mobile.


Is whatever causes the (1) situation fixed by putting a label on the drive? I was encountering some various weirdness with my USB key a long time ago, and a suggestion I found was labeling the drive with tune2fs, which seemed like a decent idea and did solve my issues.
Thanks for you reply .. but the mount point is always correct in my case.
Never had a (1) problem.

My poblem is minidlna which starts to scan on every reboot due to "wrong" database location.
 
Is whatever causes the (1) situation fixed by putting a label on the drive? I was encountering some various weirdness with my USB key a long time ago, and a suggestion I found was labeling the drive with tune2fs, which seemed like a decent idea and did solve my issues.
No, not related to label or no label in this particular case. Labeling the drive could help in other cases.

On the older code, it was easy to recreate once you knew what to look for. With a single disk set up with a directory in Media Server, do a safely remove disk from the gui. Then unplug the drive, wait a couple of seconds, then re-plug it. The drive would then be mounted with the (1) appended.
 
Thanks for you reply .. but the mount point is always correct in my case.
Never had a (1) problem.

My poblem is minidlna which starts to scan on every reboot due to "wrong" database location.
When you did your workaround test, in addition to changing the nvram variables, you had to manually put the .minidlna directory/contents back where it belonged as well.

I'm sure of the problem which was what I described. I'm testing the fix now.
 
When you did your workaround test, in addition to changing the nvram variables, you had to manually put the .minidlna directory/contents back where it belonged as well.

I'm sure of the problem which was what I described. I'm testing the fix now.
The first try was exactly according your instructions.
Meaning the "old" moved db from the first try is still in .minidlna on sda1.
But unused now ;)

Thanks for your help.
 
Hi

Will be updating to the latest 24E3 soon, just a bit confused about the certificate info you posted in post 5777.

Whats all this about generating a new certificate.

Does everyone need to do this who updates?

Thank's
 
One other thing with respect to the new https cert. With the changes that were made, including increasing the key length, the size of the cert as stored in nvram has increased by about 2K. If you are tight on nvram space, you should keep this in mind.

I've finished up the code to also move the https cert to jffs, to be part of the next release.
 
Last edited:

Sign Up For SNBForums Daily Digest

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