Aegis Aegis 1.7.x

[blueliner]

Release 1.7.4

Minor upgrade.
Added command to aegis CLI:
aegis debug

That will output all the useful information to report here in case of problems. It even outputs the CODE /CODE tags, so it is ready to be copied/pasted in this forum as is.

Same with web GUI: the debug info in the status was removed, and a debug tab was added, with the same output as the CLI (ready to copy/paste).

Hello,

Upgrade to 1.7.4 worked well from the GUI. The debug changes are a nice addition. I checked and the code generated successfully from both the debug tab and the CLI.

Thanks!
BL

 

[n1llam1]

@HELLO_wORLD,

The Aegis web cgi returns a HTTP status code 500 on clicking the Log tab the first time, although that does not prevent the page from displaying the log entries, so I don't know if you would want to look into this or not. Just for your awareness. Screen snippet attached. Thanks.

 

[HELLO_wORLD]

@HELLO_wORLD,

The Aegis web cgi returns a HTTP status code 500 on clicking the Log tab the first time, although that does not prevent the page from displaying the log entries, so I don't know if you would want to look into this or not. Just for your awareness. Screen snippet attached. Thanks.

Thanks. This is normal
uhttpd limitation (returning 500 when data is too long to its taste, but still sends the data, so it is ignored).

 

[n1llam1]

Thanks. This is normal
uhttpd limitation (returning 500 when data is too long to its taste, but still sends the data, so it is ignored).

I have questions about Aegis (which is quite new to me) after a firmware upgrade.

I already had Aegis installed on an external USB drive.

Next, what I did is: uninstall the Kamoj add-on, reboot, upgrade firmware (auto-reboot), install Kamoj add-on, reboot

After that process for firmware upgrade, I did not see the Aegis link enabled on the Kamoj Menu anymore.

/www/bolemo no longer existed

So I went through the Aegis installation process again.

The output from the re-installation process is included below (which seems to indicate that files still existed on the external drive, including the web companion):

root@R7800:~$ wget -qO- https://github.com/bolemo/aegis/raw/stable/aegis-install.sh --no-check-certificate | sh
ifconfig: ppp0: error fetching interface information: Device not found
Where do you want to install aegis?
0 - router internal memory (rootfs)
1 - external drive: /mnt/optware
2 - external drive: /mnt/sda1
c - cancel installation
Your choice: 2
aegis will be installed on external drive /tmp/mnt/sda1
Creating directory (if not already existing): /opt/scripts
Creating directory (if not already existing): /tmp/mnt/sda1/bolemo
Creating symlink (if not already existing): /opt/bolemo
Creating subdirectories in bolemo: scripts, etc
Downloading and installing aegis...
An aegis sources file already exists, keeping it.
An aegis VPN whitelist file already exists, keeping it.
iprange is installed.
Done!
root@R7800:~$ aegis info
Info:
- aegis version 1.7.4 is installed on external drive.
- latest available version: 1.7.4
- aegis is in PATH.
- iprange is installed: iprange 1.0.4
- Web Companion is installed.

Then I manually enabled Aegis with logging.

Is there one or more steps that I am missing to have the Aegis installation automatically "restored" from the external drive and auto-start after a reboot? Was it just missing symbolic links? Thanks.

 

[HELLO_wORLD]

I have questions about Aegis (which is quite new to me) after a firmware upgrade.

I already had Aegis installed on an external USB drive.

Next, what I did is: uninstall the Kamoj add-on, reboot, upgrade firmware (auto-reboot), install Kamoj add-on, reboot

After that process for firmware upgrade, I did not see the Aegis link enabled on the Kamoj Menu anymore.

/www/bolemo no longer existed

So I went through the Aegis installation process again.

The output from the re-installation process is included below (which seems to indicate that files still existed on the external drive, including the web companion):

root@R7800:~$ wget -qO- https://github.com/bolemo/aegis/raw/stable/aegis-install.sh --no-check-certificate | sh
ifconfig: ppp0: error fetching interface information: Device not found
Where do you want to install aegis?
0 - router internal memory (rootfs)
1 - external drive: /mnt/optware
2 - external drive: /mnt/sda1
c - cancel installation
Your choice: 2
aegis will be installed on external drive /tmp/mnt/sda1
Creating directory (if not already existing): /opt/scripts
Creating directory (if not already existing): /tmp/mnt/sda1/bolemo
Creating symlink (if not already existing): /opt/bolemo
Creating subdirectories in bolemo: scripts, etc
Downloading and installing aegis...
An aegis sources file already exists, keeping it.
An aegis VPN whitelist file already exists, keeping it.
iprange is installed.
Done!
root@R7800:~$ aegis info
Info:
- aegis version 1.7.4 is installed on external drive.
- latest available version: 1.7.4
- aegis is in PATH.
- iprange is installed: iprange 1.0.4
- Web Companion is installed.

Then I manually enabled Aegis with logging.

Is there one or more steps that I am missing to have the Aegis installation automatically "restored" from the external drive and auto-start after a reboot? Was it just missing symbolic links? Thanks.

Looks like the symbolic links were missing.

There should be nothing particular to do for aegis to be restored when on an external drive.

BUT, I am glad you raised that question. Because I realized that the code put in the auto mount script is depending on the symbolic link and not the full path.
I did not have a problem with it because I have the symlink restored earlier in my custom post mount script.
Nobody else referred this problem, so I suppose they have restored the symlink themselves in their scripts, or reinstalled without reporting this issue.

I corrected this in next release 1.7.5 to come ASAP.

BTW, here is how it works:
When aegis is set (meaning it has been up at least once), it adds in /mnt/EXTERNAL_DRIVE/autorun/scripts/post-mount.sh the following piece of code:

# Bolemo aegis
[ -x /tmp/mnt/EXTERNAL_DRIVE/bolemo/scripts/aegis ] && /tmp/mnt/EXTERNAL_DRIVE/bolemo/scripts/aegis _pm $1

Before it was
[ -x /opt/bolemo/scripts/aegis ] && /opt/bolemo/scripts/aegis _pm $1
And after a firmware upgrade, /opt/bolemo symlink does not exist yet, so nothing happened, explaining why you did not have the symlinks back.

Once aegis is upreared, it restores everything (symlinks)

Anyway, all should be fine with 1.7.5 (to come).

 

[HELLO_wORLD]

Release 1.7.5

Fixed the restore aegis process after firmware upgrade when on external drive. Thanks @n1llam1 to have raised this issue.

Upgrade from web (unset upgrade up method), or from terminal:

aegis unset
aegis upgrade
aegis up -v

 

[n1llam1]

Release 1.7.5

Fixed the restore aegis process after firmware upgrade when on external drive. Thanks @n1llam1 to have raised this issue.

Upgrade from web (unset upgrade up method), or from terminal:

aegis unset
aegis upgrade
aegis up -v

Thank you @HELLO_wORLD. The upgrade using the web companion was seamless to 1.7.5, as it was when I previously upgraded from 1.7.3 to 1.7.4.

I confirmed the following lines have been added at the end of the /tmp/mnt/sda1/autorun/scripts/post-mount.sh script:

# Bolemo aegis
[ -x /tmp/mnt/sda1/bolemo/scripts/aegis ] && /tmp/mnt/sda1/bolemo/scripts/aegis _pm $1

 

[NetBytes]

I have always had the same problem as @n1llam1, but thought it was related to my frequent firmware reinstalls.
I did not find the re-install of aegis too difficult to do but I am glad this is now fixed.
My post-mount.sh script is also corrected now.
Thank you @HELLO_wORLD.

 

[HELLO_wORLD]

Release 1.7.6

Minor upgrade.
Improved the auto mount code (works already with 1.7.5, but now even with aegis down [but not unset], symlink will be restored after firmware upgrade).
Corrected a minor bug in status when incorrect set in auto mount was not reported properly.

 

[NetBytes]

Clean upgrade via GUI - thanks again @HELLO_wORLD !

 

[HELLO_wORLD]

Release 1.7.7

Thanks to @NetBytes who found an issue in the symlink regeneration when upgrading firmware.
Fixed and tested here. Now this aegis surviving firmware upgrade should be fixed for good.

Sorry for the multiple upgrades today, and thanks to this great community that is giving good feedback and allow quick fixing of bugs.

 

[n1llam1]

Release 1.7.7

Thanks to @NetBytes who found an issue in the symlink regeneration when upgrading firmware.
Fixed and tested here. Now this aegis surviving firmware upgrade should be fixed for good.

Sorry for the multiple upgrades today, and thanks to this great community that is giving good feedback and allow quick fixing of bugs.

Thanks @HELLO_wORLD, you are on a roll with these enhancements. I was just about to upgrade to 1.7.6 and now it's showing 1.7.7 already . The web companion upgrade feature performed flawlessly as usual.

In case you have a wishlist, for some time down the road, would it be possible add a feature to the web companion upgrade page to display either a link to a changelog or the actual changes since the version that is currently installed on the router? Thanks.

 

[HELLO_wORLD]

Thanks @HELLO_wORLD, you are on a roll with these enhancements. I was just about to upgrade to 1.7.6 and now it's showing 1.7.7 already . The web companion upgrade feature performed flawlessly as usual.

In case you have a wishlist, for some time down the road, would it be possible add a feature to the web companion upgrade page to display either a link to a changelog or the actual changes since the version that is currently installed on the router? Thanks.

Interesting idea...

I don’t really maintain a change log for now, but aegis getting more mature, I expect less frequent updates will be required and I will be able to maintain a change log.
A link to it (and the readme page) from the web GUI would be nice, and some day a little readme for the web GUI itself.

 

[sppmaster]

Just a fact from today
IP address 140.82.121.4 is blocked by the router for WAN interface.
IP address 140.82.121.4 is in aegis global block directives.
---
This is github.com IP address. Strange don't you think.

 

[HELLO_wORLD]

Just a fact from today
IP address 140.82.121.4 is blocked by the router for WAN interface.
IP address 140.82.121.4 is in aegis global block directives.
---
This is github.com IP address. Strange don't you think.

Yes, that is unexpected. It is likely from the FireHOL level 3 list that can have false positives sometimes, but they generally fix it fast.

Solution is to comment (or remove) it to avoid risk of false positive or simply be aware it can happen (thankfully rarely) and whitelist what is wrongly blocked.

 

[NetBytes]

Yes, that is unexpected. It is likely from the FireHOL level 3 list that can have false positives sometimes, but they generally fix it fast.

Solution is to comment (or remove) it to avoid risk of false positive or simply be aware it can happen (thankfully rarely) and whitelist what is wrongly blocked.

This happened to me a few weeks ago with myshopify.com - whitelisting the ip address worked and I haven't looked back.

 

[sppmaster]

Yes, that is unexpected. It is likely from the FireHOL level 3 list that can have false positives sometimes, but they generally fix it fast.

Solution is to comment (or remove) it to avoid risk of false positive or simply be aware it can happen (thankfully rarely) and whitelist what is wrongly blocked.

A few minutes ago it's fixed with latest update. But I wonder how the updates completed successfully when the update server itself was blacklisted and I didn't add it to the whitelist.
@HELLO_wORLD Maybe you can explain.
Or it's simply on different IP - raw.githubusercontent.com (185.199.111.133)
I hope it won't get blacklisted by mistake someday.

@HELLO_wORLD
Really strange but an hour later I'm unable to access github again. This time I added it to the whitelist because I needed an access to it.

 

[n1llam1]

A few minutes ago it's fixed with latest update. But I wonder how the updates completed successfully when the update server itself was blacklisted and I didn't add it to the whitelist.
@HELLO_wORLD Maybe you can explain.
Or it's simply on different IP - raw.githubusercontent.com (185.199.111.133)
I hope it won't get blacklisted by mistake someday.

@HELLO_wORLD
Really strange but an hour later I'm unable to access github again. This time I added it to the whitelist because I needed an access to it.

In my case, Aegis is reporting that it's not blocking 185.199.111.133, although it is blocking 140.82.121.4. I don't have any entries in the whitelist.

 

[HELLO_wORLD]

In my case, Aegis is reporting that it's not blocking 185.199.111.133, although it is blocking 140.82.121.4. I don't have any entries in the whitelist.

View attachment 31999

Ok, the --- here separate different tests, so you did test 185.199.111.133 that is not blocked. Then you tested 140.82.121.4 that is blocked because it is in the global blocklist.
Likely from the FireHOL level 3 list that for some reason considers that IP a threat.

For the rest, you guessed well. GitHub has many mirrors and specific IPs, and the default sources list uses addresses raw.github...

Putting 140.82.121.4 in the whitelist is the solution.
The good thing is if it is not in the blacklist anymore, aegis won’t load the address in the master whitelist, but if it reappears, it will add it again. So don’t be afraid of memory or process time if you leave IPs in the whitelist. Only blacklisted IP that are in the whitelist (the one you edit) are loaded in the whitelist in memory.

 

[mith_y2k]

Just a fact from today
IP address 140.82.121.4 is blocked by the router for WAN interface.
IP address 140.82.121.4 is in aegis global block directives.
---
This is github.com IP address. Strange don't you think.

Interestingly our company had an “outage” because github was blocked. I guess one or more of their IPs ended in the wrong list