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

[punchsuckr]

Removed it but only worked once upon a soft reboot. When i powered off and restarted while it was scanning, it quit again.

Edit: Seems its partially fixed. Media server starts up when i reboot via gui but same old behaviour if i physically switch it off and on again while its still scanning the media. Havent tested what happens when scanning has completed and with n without the scan media on every boot.

Edit2: quit again on a soft reboot. Not dependable.

Edit3: its following a predictable pattern now... When the scanning is idle and i soft reboot, media server starts up fine when it comes online and starts scanning normally.

Now when i soft reboot (while it is scanning), it quits when the router comes back online.

 

[punchsuckr]

The log when it quits now:

Jan  1 05:30:32 rc_service: waiting "start_firewall" via udhcpc ...
Jan  1 05:30:32 rc_service: hotplug 327:notify_rc restart_nasapps
Jan  1 05:30:32 rc_service: waiting "start_firewall" via udhcpc ...
Jan  1 05:30:33 dnsmasq-dhcp[623]: DHCPREQUEST(br0) *******
Jan  1 05:30:33 dnsmasq-dhcp[623]: DHCPACK(br0) *******
Jan  1 05:30:35 WAN Connection: WAN was restored.
Jan  1 05:30:35 start_nat_rules: apply the nat_rules (/tmp/nat_rules)!
Jan  1 05:30:36 dnsmasq-dhcp[623]: DHCPREQUEST(br0) *******
Jan  1 05:30:36 dnsmasq-dhcp[623]: DHCPACK(br0) *******
Jan  1 05:30:39 start_nat_rules: (/tmp/nat_rules) cancelled!
Jan  1 05:30:40 rc_service: wanduck 484:notify_rc start_apps_update
Jan  1 05:30:40 rc_service: waiting "start_firewall" via udhcpc ...
Jan  1 05:30:41 dnsmasq-dhcp[623]: DHCPREQUEST(br0)*******
Jan  1 05:30:41 dnsmasq-dhcp[623]: DHCPACK(br0) *******
Jan  1 05:30:43 rc_service: skip the event: restart_nasapps
Jan  1 05:30:46 start_nat_rules: apply the nat_rules (/tmp/nat_rules_eth0_eth0)!
Jan  1 05:30:46 start_nat_rules: (/tmp/nat_rules_eth0_eth0) success!
Jan  1 05:30:47 kernel: nf_conntrack_rtsp v0.6.21 loading
Jan  1 05:30:47 kernel: nf_nat_rtsp v0.6.21 loading
Jan  1 05:30:49 rc_service: udhcpc 606:notify_rc start_upnp
Jan  1 05:30:49 rc_service: waiting "stop_upnp" via udhcpc ...
Jan  1 05:30:50 ddns: clear ddns cache file for server/hostname change

The log when it works normally:

Jan  1 05:30:32 rc_service: hotplug 327:notify_rc restart_nasapps
Jan  1 05:30:32 NFS Server: daemon is stopped
Jan  1 05:30:32 MediaServer: daemon is stopped
Jan  1 05:30:32 FTP Server: daemon is stopped
Jan  1 05:30:33 Samba Server: smb daemon is stopped
Jan  1 05:30:33 Samba Server: daemon is started
Jan  1 05:30:33 MediaServer: daemon is started
Jan  1 05:30:34 rc_service: udhcpc 606:notify_rc stop_upnp
Jan  1 05:30:34 rc_service: waiting "start_firewall" via udhcpc ...
Jan  1 05:30:35 WAN Connection: WAN was restored.
Jan  1 05:30:35 start_nat_rules: apply the nat_rules (/tmp/nat_rules)!
Jan  1 05:30:36 dnsmasq-dhcp[627]: DHCPREQUEST(br0) **** 
Jan  1 05:30:36 dnsmasq-dhcp[627]: DHCPACK(br0) ****
Jan  1 05:30:37 dnsmasq-dhcp[627]: DHCPREQUEST(br0) **** 
Jan  1 05:30:37 dnsmasq-dhcp[627]: DHCPACK(br0) ****
Jan  1 05:30:37 dnsmasq-dhcp[627]: DHCPREQUEST(br0) **** 
Jan  1 05:30:37 dnsmasq-dhcp[627]: DHCPACK(br0) ****
Jan  1 05:30:39 start_nat_rules: (/tmp/nat_rules) cancelled!
Jan  1 05:30:40 rc_service: wanduck 484:notify_rc start_apps_update
Jan  1 05:30:40 rc_service: waiting "start_firewall" via udhcpc ...
Jan  1 05:30:41 kernel: eth2: received packet with  own address as source address
Jan  1 05:30:48 start_nat_rules: apply the nat_rules (/tmp/nat_rules_eth0_eth0)!
Jan  1 05:30:48 start_nat_rules: (/tmp/nat_rules_eth0_eth0) success!
Jan  1 05:30:48 HTTP login: login 'admin' successful from 192.168.1.111
Jan  1 05:30:48 kernel: nf_conntrack_rtsp v0.6.21 loading
Jan  1 05:30:48 kernel: nf_nat_rtsp v0.6.21 loading
Jan  1 05:30:52 rc_service: udhcpc 606:notify_rc start_upnp
Jan  1 05:30:52 rc_service: waiting "stop_upnp" via udhcpc ...

Btw if media server stalls from some other service starting at the same time, could it be some other critical service stalls as well? I can see it waiting for start_firewall, does it ever start??!
I guess the firewall starts with the one with "start_nat_rules...".

 

[john9527]

@punchsuckr

Progress.....A couple of things....

It's still trying to update DM (start_apps_update).....do you have Entware/Optware installed? If not, it looks like the uninstall of DM wasn't complete. If no Entware/Optware, please telnet/ssh to the router and

rm -rf /opt

Do you remember if there is 'check for updates' function in DM? My first inclination is to just disable this update check to avoid problems in the future (especially if it's being triggered by an Entware/Optware install).

I'm not sure what happens if you reboot in the middle of a minidlna scan....the media db could be left in a bad state. One thing to check now, is the minidlna log file.....

cat /mnt/name_of_your_media_mountpoint/your_media_dir/.minidlna/minidlna.log

Re other processes.....as I said they used a special call for the nsapps start. And yes, start_nat_rules is part of firewall start. If you want to see it get to the end of starting the firewall, make a dummy firewall-start script (just a shebang and exit) which will be processed at the end of firewall start and make a log entry.

 

[punchsuckr]

No I didn't install entware/optware. Will run the command and post back. I do remember there being any option to check for updates in dm.

Should I also remove asusware directory from the drive?
EDIT: Guessing that rm command does this.

And holy crap that asusware folder is over 3.2GB on the disk..!? While the size is 42.2mb.

Its giving me a "rm: can't remove '/opt': Read-only file system" error. Tried unsetting asusware as read only, seems to do it but still does't unset.

 

[john9527]

No I didn't install entware/optware. Will run the command and post back. I do remember there being any option to check for updates in dm.

Should I also remove asusware directory from the drive?

Hmm...hold off a minute if you haven't done it yet. I need to check something..

 

[punchsuckr]

Another edit in the above post John. I wrote do instead of don't. There isn't an option to disable updating in dm. Checked again after installing ans uninstalling again.

 

[john9527]

@punchsuckr - Sorry I wasn't clear....I was asking if there was an option to 'check for updates', not to 'disable updates'.

But, at this point, I'm sorry to have to ask you to do a factory reset and reconfig. It really looks like there are remnants of DM around and the installed apps status may be corrupted. Rather than flog ourselves, I think starting fresh may be best.

 

[punchsuckr]

@punchsuckr - Sorry I wasn't clear....I was asking if there was an option to 'check for updates', not to 'disable updates'.

But, at this point, I'm sorry to have to ask you to do a factory reset and reconfig. It really looks like there are remnants of DM around and the installed apps status may be corrupted. Rather than flog ourselves, I think starting fresh may be best.

hmm.. Oh well.. I modified the permission to writable on /opt. Should i first give that a try? And a reset isn't much of an issue if it gets it to run well.

EDIT: Nope the permission didn't work. Sorry for the many edits..permissions worked. Trying to remove and see if it works.

 

[john9527]

hmm.. Oh well.. I modified the permission to writable on /opt. Should i first give that a try? And a reset isn't much of an issue if it gets it to run well.

No, I don't think it will help and the bad condition will just be recreated on the next boot because of something wrong in the apps_status (it's actually /opt/lib that's being populated). Let's start clean.

 

[punchsuckr]

No, I don't think it will help and the bad condition will just be recreated on the next boot because of something wrong in the apps_status (it's actually /opt/lib that's being populated). Let's start clean.

Ok John.. resetting now.

 

[punchsuckr]

In the process of setting it up again.. The thought struck me that given the vulnerability in WPS it should be disabled out of the box. One less job to do and it will be fine if somebody forgets to do it.
Is there a possibility of this happening @john9527 ?

 

[john9527]

In the process of setting it up again.. The thought struck me that given the vulnerability in WPS it should be disabled out of the box. One less job to do and it will be fine if somebody forgets to do it.
Is there a possibility of this happening @john9527 ?

Good idea.....I'll take a look.

EDIT: Done for next update.

 

[punchsuckr]

Good idea.....I'll take a look.

EDIT: Done for next update.

And it has been fixed! The log messages look quite similar to what you posted with the waiting restart nasapps.
Too bad i had to reset but who would've thought that old bs bt client would cause problems. @john9527 would have thought that's who.

Thanks for your support man.

 

[john9527]

And it has been fixed! The log messages look quite similar to what you posted with the waiting restart nasapps.

Fantastic! I was preparing for a hard debug if the reset didn't work
And thank you for your willingness to work on the problem.

 

[punchsuckr]

Fantastic! I was preparing for a hard debug if the reset didn't work
And thank you for your willingness to work on the problem.

Thats what i did for a living for 2 years
I would also like to mention that i first removed the hard drive, completely deleted the asusware folder, reset to factory default with the disk detached, power cycled and then configured the router, subsequently attaching the disk. Could come in useful for somebody in the future. I then tested with multiple cold and soft reboots...
I know some of it must be overkill but i did it anyway.

 

[john9527]

Just a quick FYI for everyone...I found a bug where having QoS starting at boot time (either traditional or bandwidth limiter) can break NAT loopback in the V17E2 release. As a temporary fix you can go to the main QoS page under traffic manager after the boot completes and hit Save (with or without making any other changes). That should bring back the NAT loopback functionality.

I plan out on putting out an update release with a fix over the weekend. Thanks.

 

[Zin105]

Just a quick FYI for everyone...I found a bug where having QoS starting at boot time (either traditional or bandwidth limiter) can break NAT loopback in the V17E2 release. As a temporary fix you can go to the main QoS page under traffic manager after the boot completes and hit Save (with or without making any other changes). That should bring back the NAT loopback functionality.

I plan out on putting out an update release with a fix over the weekend. Thanks.

Sorry but there must be some more problems with NAT loopback. Tried all your previous advice, including this one and restoring factory defaults, nothing fixed it. Flashed 16E and it instantly worked again.

I even loaded the saved config file from 17E to 16E and it still works.

 

[john9527]

Sorry but there must be some more problems with NAT loopback. Tried all your previous advice, including this one and restoring factory defaults, nothing fixed it. Flashed 16E and it instantly worked again.

I even loaded the saved config file from 17E to 16E and it still works.

I've been trying everything I can think of to make it fail, and the scenario above is the only thing I've been able to come with. Exactly what services/options are you using?

Then, let's start from the beginning....

iptables -t mangle -Z
ipttables -t nat -Z

wait a few seconds, then do something that should use NAT loopback, and capture the following output. I'll send you a PM with my email address to send it to.

iptables -t mangle -L -v
iptables -t nat -L -v

 

[Zin105]

I've been trying everything I can think of to make it fail, and the scenario above is the only thing I've been able to come with. Exactly what services/options are you using?

Then, let's start from the beginning....

iptables -t mangle -Z
ipttables -t nat -Z

wait a few seconds, then do something that should use NAT loopback, and capture the following output. I'll send you a PM with my email address to send it to.

iptables -t mangle -L -v
iptables -t nat -L -v

Trying my web server (wamp) and FTP mainly and both fail. Sent you the email now.

 

[Koguma]

I'm not sure if this was mentioned in earlier posts (I couldn't get through the 172 pages). There seems to be a bug where I'm unable to upload the saved config. You choose a file, and hit 'UPLOAD' but no upload actually happens. I even had a backup for this same identical version and assumed maybe it needs the same filename, but no go. It just doesn't accept any file for nvram restore.