What's new

Tutorial How to monitor DNS traffic in real-time

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

... since the last batch of Entware updates a week or so ago I'm now getting lots of warning messages about egrep/grep when I run this script now?

I just noticed this yesterday. It happens when we use entware /opt/bin/egrep. If we use /bin/egrep there is no such error.

....

Quick fix is to either change to grep -E or /bin/egrep
It's possible that all this could be a sign that you might have a system-wide issue in all your interactive sessions because the PATH environment variable may not be set up correctly. All the "/opt/..." paths from Entware should be found toward the end and *not* at the beginning of the PATH definition.

The PATH var should look something like this:
Code:
/tmp/home/root$ echo $PATH
/bin:/usr/bin:/sbin:/usr/sbin:/home/{ADMIN_USER}:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin:/opt/root/.local/opt/bin:/jffs/scripts

If you see any "/opt/.." paths at the beginning, you will need to modify the Entware "/opt/etc/profile" file as recommended in this post.

HTH.
 
It's possible that all this could be a sign that you might have a system-wide issue in all your interactive sessions because the PATH environment variable may not be set up correctly. All the "/opt/..." paths from Entware should be found toward the end and *not* at the beginning of the PATH definition.

The PATH var should look something like this:
Code:
/tmp/home/root$ echo $PATH
/bin:/usr/bin:/sbin:/usr/sbin:/home/{ADMIN_USER}:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin:/opt/root/.local/opt/bin:/jffs/scripts

If you see any "/opt/.." paths at the beginning, you will need to modify the Entware "/opt/etc/profile" file as recommended in this post.

HTH.
I updated /opt/etc/profile according to your post and it seems the path has not changed.

Code:
admin@RT-AC86U-DBA8:/tmp/mnt/amtm/entware/etc# which egrep
/opt/bin/egrep
admin@RT-AC86U-DBA8:/tmp/mnt/amtm/entware/etc# sh -x profile
+ CHECK_OPT_PATH=1
+ [ 1 = 1 ]
+ is_substring /opt/bin /opt/bin:/opt/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/home/admin:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin
+ return 0
+ [ 0 == 1 ]
+ is_substring /opt/sbin /opt/bin:/opt/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/home/admin:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin
+ return 0
+ [ 0 == 1 ]
+ export TERMINFO=/opt/share/terminfo
+ export TERM=xterm
+ export TMP=/opt/tmp
+ export TEMP=/opt/tmp
+ unset LD_PRELOAD
+ unset LD_LIBRARY_PATH
+ alias mc=mc -c
+ export LANG=en_US.UTF-8
+ export LC_ALL=en_US.UTF-8
admin@RT-AC86U-DBA8:/tmp/mnt/amtm/entware/etc#
admin@RT-AC86U-DBA8:/tmp/mnt/amtm/entware/etc#
admin@RT-AC86U-DBA8:/tmp/mnt/amtm/entware/etc# which egrep
/opt/bin/egrep
admin@RT-AC86U-DBA8:/tmp/mnt/amtm/entware/etc# echo $PATH
/opt/bin:/opt/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/home/admin:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin
 
I updated /opt/etc/profile according to your post and it seems the path has not changed.

Code:
admin@RT-AC86U-DBA8:/tmp/mnt/amtm/entware/etc# which egrep
/opt/bin/egrep
admin@RT-AC86U-DBA8:/tmp/mnt/amtm/entware/etc# sh -x profile
...
..
/opt/bin/egrep
admin@RT-AC86U-DBA8:/tmp/mnt/amtm/entware/etc# echo $PATH
/opt/bin:/opt/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/home/admin:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin
The profile must be "sourced" *not* executed on a separate shell process.
This is what happens in every interactive shell session.

Example:
Bash:
source /opt/etc/profile

#OR#

. /opt/etc/profile
 
IOW, close your current session and start a new one so that the new profile will take effect then and in future sessions.
Thanks @Martinski . Fixed after a reboot.

Code:
admin@RT-AC86U-DBA8:/tmp/home/root# echo $PATH
/bin:/usr/bin:/sbin:/usr/sbin:/home/admin:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin
admin@RT-AC86U-DBA8:/tmp/home/root# which egrep
/bin/egrep
admin@RT-AC86U-DBA8:/tmp/home/root#
 
@eibgrad

Actually, just replacing the 3 (I think?) instances of "egrep" with "grep -E" seems to do the trick.
But you should check it out and maybe publish an update if you feel so inclined?
I haven't heard from @eibgrad in such a long time, I'm worried about him. :( I had even reached out to him via PM a few months ago, with no answer. I absolutely love this tool as well, and may end up hosting it myself in order to preserve it... I'll apply the necessary fixes if needed.

EDIT: It looks like @Martinski's fix resolves the issue.
 
Last edited:
Thanks @Martinski . Fixed after a reboot.

Code:
admin@RT-AC86U-DBA8:/tmp/home/root# echo $PATH
/bin:/usr/bin:/sbin:/usr/sbin:/home/admin:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin
admin@RT-AC86U-DBA8:/tmp/home/root# which egrep
/bin/egrep
admin@RT-AC86U-DBA8:/tmp/home/root#
Thank you as well, @Martinski! Your suggested modification of the opt/etc/profile file did the trick! So something wrong right out of the box on 388.1? I just did a completely fresh install yesterday when I set up my new AX6000.
 
All the "/opt/..." paths from Entware should be found toward the end and *not* at the beginning of the PATH definition.
There is no clear agreement of where in the path the opt directories "should" appear. As RMerlin explained in another thread there was a disagreement over this matter between himself and the Entware maintainer.

There are arguments in favour of opt appearing at the beginning on the path.

1. Historical precedent. It's always be the case that if Entware is installed by default it will prepend the opt directories to the path.
2. If you're installing a different version of some built-in command/package then you've made a deliberate choice to use that in preference.

Whether one way or the other is "right" is academic. The reality is that if you simply install Entware, opt will be at the beginning of the path. If a script writer or user installs conflicting packages then it's mostly their responsibility to make sure it doesn't break anything. It shouldn't be down to the average end-user that's "blindly" installing some add-on script to have to debug their environment.
 
I, for one, much prefer /opt at the beginning of my path. I have installed a number of commands that the busybox version falls short on.
There is quite a difference between /bin/ps and /opt/bin/ps.
 
There is no clear agreement of where in the path the opt directories "should" appear. As RMerlin explained in another thread there was a disagreement over this matter between himself and the Entware maintainer.
Yeah, there seems to be a long-standing disagreement on what the "right thing to do" should be; and it looks like we might be on different sides of that disagreement, and it certainly won't be resolved any time soon, so we'll have to agree to disagree on the pros & cons.

Whether one way or the other is "right" is academic. The reality is that if you simply install Entware, opt will be at the beginning of the path.
Sure, it's "academic" until the moment that the system starts to "misbehave" in some way, or some shell script & add-on no longer function as before, exhibiting some odd behavior, or new error/warning messages begin popping up, so you need to figure out what the root cause of the problem is and then need a solution.

FWIW, my preference is to always avoid, as much as possible, disrupting or interfering with the original, native environment because embedded systems tend to be tightly coupled with the specific functionality/behavior of their own built-in commands. Therefore, when installing Entware, my solution is to give higher precedence to the native built-in commands at the point where the PATH environment variable is modified.

Now, whenever I want to intentionally call the Entware version of a specific command instead of the built-in version, I have the following options:

1- Inside my own custom shell scripts I can call the command using its full path (e.g. /opt/bin/grep), or I can change the PATH environment variable locally within the script itself to satisfy its own runtime requirements:

For example:
Bash:
#!/bin/sh
#
PATH="/opt/bin:/opt/sbin:$PATH"
...

2- For interactive shell sessions, I've created custom aliases to call the specific Entware versions:

For example:
Bash:
alias optps='/opt/bin/ps'
alias optwget='/opt/bin/wget'
alias optgrep='/opt/bin/grep'
alias optegrep='/opt/bin/egrep'
...

This way I can either call the built-in commands as usual or run their Entware counterparts via their associated aliases *without* affecting anything else that expects the built-in versions to run without any complications.

IMO, this is the simplest solution, especially for the average user. The alternative would be to start editing every custom script and add-on that no longer behaves "normally" (e.g. new errors/warning msgs showing up), or request their authors to change their code to accommodate the modified Entware PATH environment.

Ultimately, of course, it’s up to each user to decide & choose what the best, simplest solution is for them, their particular preferences & their specific goals for installing Entware.

Just my 2 cents.
Enjoy the Holidays!
 
Last edited:
Thank you as well, @Martinski! Your suggested modification of the opt/etc/profile file did the trick! So something wrong right out of the box on 388.1? I just did a completely fresh install yesterday when I set up my new AX6000.
It's not the firmware's fault. The PATH environment variable is modified by Entware's profile. Whether that's right or wrong, it's up for debate; but that's the cause of the problem where a different version of the command (not the expected built-in version) is executed.
 
Yeah, there seems to be a long-standing disagreement on what the "right thing to do" should be; and it looks like we are on different sides of that disagreement, and it certainly won't be resolved any time soon, so we'll have to agree to disagree on the pros & cons.
We're not on different sides because I haven't taken a side on this issue. I have no strong opinion either way as both approaches have problems. Personally I'm of the view that software should "just work" out of the box without the end-user having to edit system files. Unfortunately because of the way Entware installs itself this is not possible (for interactive sessions). Damned if you do and damned if you don't.
 
I absolutely love this tool as well, and may end up hosting it myself in order to preserve it... I'll apply the necessary fixes if needed.
@Viktor Jaep

Do I feel a DNSMon in our future?
Or maybe Page 7 in RTRMon?

Ultimately, of course, it’s up to each user to decide & choose what the best, simplest solution is for them, their particular preferences & their specific goals for installing Entware.
I can see pro and cons for both approaches so as an average user with just enough *nix knowledge to be dangerous it's left me in a lather of indecision!

I may have to solve it by over-indulging in some Xmas fare and pondering further...

Happy Holidays everyone and thanks for your learned input to my revival of this thread and (seemingly) innocent enquiry.
 
Last edited:
We're not on different sides because I haven't taken a side on this issue.
Ah, my mistake then. Apologies.

Personally I'm of the view that software should "just work" out of the box without the end-user having to edit system files.
Fully agree, and that's certainly my expectation as well, both from an end-user and a s/w developer perspective. However, when issues do come up, I'd like to try first the solution that creates minimal disruption or interference with the native system environment, hence my recommended approach.

Unfortunately because of the way Entware installs itself this is not possible (for interactive sessions). Damned if you do and damned if you don't.
Indeed.
 
@Viktor Jaep

Do I feel a DNSMon in our future?
Or maybe Page 7 in RTRMon?


I can see pro and cons for both approaches so as an average user with just enough *nix knowledge to be dangerous it's left me in a lather of indecision!

I may have to solve it by over-indulging in some Xmas fare and pondering further...

Happy Holidays everyone and thanks for your learned input to my revival of this thread and (seemingly) innocent enquiry.
I think he might already be working on a

PATHMon
 
Sorry to belabor this, but this discussion has been extremely illuminating to me.

I notice that each of the S01, etc calling scripts I have includes the same PATH statement, with the opt directories first, then the usr directories and ending with the /bin directories. I take it this overrides the profile version for that script, and that given the default install, this PATH statement is redundant?
 
Sorry to belabor this, but this discussion has been extremely illuminating to me.
I agree with your assessment on this one @elorimer ... very interesting and illuminating. I don't pretend to understand its complexities, but as with a Windows PATH statement, you insert the folder you need, and bam... it just works. Here there seems to be multiple ways of doing things that yield different results, which may or may not be the best depending on which side of the "best practices" argument you fall on. I will definitely keep learning and watching more on this to get a better understanding.
 
I take it this overrides the profile version for that script, and that given the default install, this PATH statement is redundant?
The path set in the profile is only used for terminal sessions. So it's not applicable for services that are started up automatically by the router. However, if you were to run any of the S* scripts manually from the command line then any path that is set in the script takes precedence.

So the problem of precedence only arises with terminal sessions.
 
I have unbound and route it over vpn. It used to be all green. But few days ago I noticed a lot of red entry with my WAN as source. The recipient dst side still show my vpn ip though. Any idea what could possibly cause this?
D3530423-AFE6-43E9-A595-FEBF825D7DB8.jpeg
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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