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

[atkinsom]

Thank You guys for the info. OpenVPN warning Message disappears but still no joy as the handshake never completes. I hope I don't have to generate new keys after upgrading to 25E1 with the 2.4.2 OpenVPN. Are there any other settings I need to make in the GUI to get it to connect or just modifying the config file is sufficient.

 

[john9527]

This is perfectly normal. It simply indicates that one of the modules has a proprietary license instead of GPL, therefore that specific debug feature isn't enabled in the kernel. This has always been the case.

The only interesting thing I saw....on my AC68R (A2 rev) that doesn't support FA, it get the ctf taints module message.....on my AC68P which does support FA, the taint message refers to 'et' instead of ctf. Looks like only the first 'tainting' module gets logged.

 

[john9527]

Thank You guys for the info. OpenVPN warning Message disappears but still no joy as the handshake never completes. I hope I don't have to generate new keys after upgrading to 25E1 with the 2.4.2 OpenVPN. Are there any other settings I need to make in the GUI to get it to connect or just modifying the config file is sufficient.

Shouldn't have to regenerate any of the keys.....the options that are auto gen'd by the server were changed because of the deprecated function.

 

[RMerlin]

Looks like only the first 'tainting' module gets logged.

That would also be my guess.

 

[conquer22]

Hi John and Merlin,
Would it be possible to relink the autochecking new firmware to your location instead of Asus's site? It would be nice to have it autoupdate with beta check box.
Thanks to both for the hard work

 

[slobodan]

Figured it out: dnsmasq.conf.add wasn't the problem; the problem was that the entware-ng services got executed before /jffs/scripts/wan-start.

So, I have disabled pixelserv, then I have enabled pixelserv (this did away with the 0.0.0.0 lines in /etc/dnsmasq.conf). Then I have added this to /opt/etc/init.d/S80pixelserv-tls (just under #!/bin/sh):

# DO NOT EDIT this part of the file #
# generated by AB-Solution 3.8
psState=on
if [ $psState == "on" ];then
        ifconfig br0:pixelserv 192.168.2.2 up
        logger "AB-Solution created br0:pixelserv 192.168.2.2 via $0"
fi
# end of DO NOT EDIT #

Then rebooted and all is ok. (I've changed the IP, but that wasn't needed.)

 

[atkinsom]

Shouldn't have to regenerate any of the keys.....the options that are auto gen'd by the server were changed because of the deprecated function.

Looks like something went awry when I did the update over the VPN from a remote computer. I got home and re flashed the firmware to 25e1 and this time everything worked perfect after the reboot. Lesson here is not to do a firmware update from a remote system but rather do an RDP to a computer on the local network and flash in that manner. Anyway sorry for all the posts. Cheers.

 

[thelonelycoder]

Figured it out: dnsmasq.conf.add wasn't the problem; the problem was that the entware-ng services got executed before /jffs/scripts/wan-start.

So, I have disabled pixelserv, then I have enabled pixelserv (this did away with the 0.0.0.0 lines in /etc/dnsmasq.conf). Then I have added this to /opt/etc/init.d/S80pixelserv-tls (just under #!/bin/sh):

# DO NOT EDIT this part of the file #
# generated by AB-Solution 3.8
psState=on
if [ $psState == "on" ];then
        ifconfig br0:pixelserv 192.168.2.2 up
        logger "AB-Solution created br0:pixelserv 192.168.2.2 via $0"
fi
# end of DO NOT EDIT #

Then rebooted and all is ok. (I've changed the IP, but that wasn't needed.)

The order in which these files gets executed is dynamic during boot, changing what you did might not always work..
In any case, the S80pixelserv-tls file will be replaced every time you change something that involves pixelserv.
So your edit will be wiped out.

What you CAN do is add a pause to the file your pasted content is in, /jffs/scripts/wan-start.
Add this right after the shebang (#!/bin/sh):
sleep 2

Increase the number, it's seconds. Don't make that too high, or pixelserv will not be able to start because the virtual interface is not up (ifconfig br0ixelserv 192.168.2.2 up)

I have no idea why you seem to have problems with it, this runs on thousands of routers without problems.

 

[thelonelycoder]

Then rebooted and all is ok. (I've changed the IP, but that wasn't needed.)

What do you mean by that? The IP HAS TO BE the one set as pixelserv IP.
If you set it to anything else then explain to me why you think that is a good idea.

 

[slobodan]

What do you mean by that? The IP HAS TO BE the one set as pixelserv IP.
If you set it to anything else then explain to me why you think that is a good idea.

Yes, I have changed the settings: router IP, pixelserv IP, did not help. What helped was copy/pasting those lines there. I have commented out the ifconfig from wan-start.

 

[slobodan]

The order in which these files gets executed is dynamic during boot, changing what you did might not always work..
Increase the number, it's seconds. Don't make that too high, or pixelserv will not be able to start because the virtual interface is not up (ifconfig br0ixelserv 192.168.2.2 up)

As I have said, wan-start gets executed after S80pixelserv-tls. So, the number would have to be negative (it does not work that way).

 

[slobodan]

 grep created /tmp/syslog*
Jan  1 00:00:34 admin: AB-Solution created br0:pixelserv 192.168.2.2 via /opt/etc/init.d/S80pixelserv-tls
Jan  1 00:00:47 admin: AB-Solution created br0:pixelserv 192.168.2.2 via /jffs/scripts/wan-start

To be sure, dnsmasq still dies unexpectedly, but less frequently than before.

 

[john9527]

The order in which these files gets executed is dynamic during boot, changing what you did might not always work..

This is something that anyone who writes scripts always needs to keep in mind.....all the script execution is event driven. So, you can never depend on things happening in a specific order, and if there is a dependency for your script, you need to check for it.

The execution can change from release to release (a new function may delay an event for example), or even between boots (your ISP may be a bit slow one day delaying the WAN coming up or your selected time server may be slow or down, delaying events that require a valid time as some examples).

 

[slobodan]

This is something that anyone who writes scripts always needs to keep in mind.....all the script execution is event driven. So, you can never depend on things happening in a specific order, and if there is a dependency for your script, you need to check for it.

The execution can change from release to release (a new function may delay an event for example), or even between boots (your ISP may be a bit slow one day delaying the WAN coming up or your selected time server may be slow or down, delaying events that require a valid time as some examples).

I did not have this problem on my AC56U before build 25B7. I don't have this problem on a RT-N16 with build 25J1. The two routers are configured similarly (not the same, but much alike).

 

[Chazall1]

All working as expected here. Thanks for your work.

 

[john9527]

@slobodan - Just speculating, but pixelserv may be starting 'faster' since I've included haveged (the entropy required for cert generation will be available sooner?). I did see that DNSCrypt will start faster on V25 for that reason.

 

[thelonelycoder]

This is something that anyone who writes scripts always needs to keep in mind.....all the script execution is event driven. So, you can never depend on things happening in a specific order, and if there is a dependency for your script, you need to check for it.

The execution can change from release to release (a new function may delay an event for example), or even between boots (your ISP may be a bit slow one day delaying the WAN coming up or your selected time server may be slow or down, delaying events that require a valid time as some examples).

So, ahh, you suggest I add more tests to check the checks?
This is not a commen problem in AB. In fact, this is the first time I read and heard about it.
At the moment and with the posted responds by the user I am not sure this has anything to do with AB.
Who knows what else is in the user scripts?

But thanks John, your input is always welcome and I keep your words in mind.

 

[thelonelycoder]

I did not have this problem on my AC56U before build 25B7. I don't have this problem on a RT-N16 with build 25J1. The two routers are configured similarly (not the same, but much alike).

I'm going to excuse myself from this discussion at this time.
If you meddle with AB's scripts then I give up.
Check what other scripts you may run from jffs and disable them first before modifying AB scripts.

 

[slobodan]

Well, now I am looking to see how it works after performing

#!/bin/sh
sed -i -e 's/\:\:/::1/g' ab-solution.sh
sed -i -e 's/0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/g' ab-solution.sh

And then updating the hosts and rebooting.

If this does not seem to prevent dnsmasq from dying, I will try:

#!/bin/sh
nvram unset lan_domain
nvram commit
reboot

 

[thelonelycoder]

Well, now I am looking to see how it works after performing

#!/bin/sh
sed -i -e 's/\:\:/::1/g' ab-solution.sh
sed -i -e 's/0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/g' ab-solution.sh

And then updating the hosts and rebooting.

If this does not seem to prevent dnsmasq from dying, I will try:

#!/bin/sh
nvram unset lan_domain
nvram commit
reboot

Good night, I need to rest now.