Entware Entware armv7sf-k2.6 EOS

[garycnew]

@thelonelycoder I ran into an issue, attempting to use python's ssl (python3-openssl) module, with the armv7sf-k2.6 repo's, in that ssl appears to function properly with the entware and garycnew repos' python3-openssl packages, but doesn't seem to work with the maurer repo's python3-openssl package.

entware:

# python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 3.0.10 1 Aug 2023
# openssl version
OpenSSL 1.1.1w  11 Sep 2023

maurer:

# python -c "import ssl; print(ssl.OPENSSL_VERSION)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/lib/python3.11/ssl.py", line 100, in <module>
ImportError: /opt/lib/python3.11/lib-dynload/_ssl.cpython-311-arm-linux-gnueabi.so: symbol COMP_get_type, version OPENSSL_3.0.0 not defined in file libcrypto.so.3 with link time reference

garycnew:

# python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 3.0.14 4 Jun 2024
# openssl version
OpenSSL 1.1.1w  11 Sep 2023

I'm trying to understand whether it's strictly an issue with maurer's repo, an issue with mixed packages from the combination of armv7sf-k2.6 repo's, or something else.

If you could attempt to reproduce each case, I would be greatly appreciative.

Respectfully,


Gary

 

[garycnew]

@thelonelycoder

In addition to Maurer discontinuing their armv7sf-k2.6 repo, the primary reason I decided to take-up the torch to continue building an armv7sf-k2.6 repo is because Maurer's repo lacked some of the packages (nmap-full) and depenencies (liblua-5.4) that I needed and felt it would be more stable building my own stack.

While the garycnew repo is now the primary backport used (when enabled), I'm concerned that combining the entware base, maurer, and garycnew backport repos may lead to dependency conflicts and issues. The Entware dependency logic is fairly rudimentary and only looks to see whether the dependent package exists and sometimes requires a specific version.

Would it be possible to modify amtm (when enabled) to specify a particular backport repo; similar, to the entware base repo? I believe it would be better to stick within a backport repo where applications and dependencies were built for one another. Moreover, if someone wants to add an alternative package, they can download and add the package manually, at their sole discretion, to confirm whether it works or not.

I appreciate your consideration.

Respectfully,


Gary

 

[thelonelycoder]

Would it be possible to modify amtm (when enabled) to specify a particular backport repo; similar, to the entware base repo? I believe it would be better to stick within a backport repo where applications and dependencies were built for one another. Moreover, if someone wants to add an alternative package, they can download and add the package manually at their sole discretion to confirm whether it works or not.

I appreciate your consideration.

I rely on your expertise and far better judgement. Therefore, I am going to drop maurers backport for these routers, as originally mentioned and suggested by you.
I appreciate your commitment and determination for this project.

 

[thelonelycoder]

amtm 6.1.2 is now out.

 

[garycnew]

I rely on your expertise and far better judgement. Therefore, I am going to drop maurers backport for these routers, as originally mentioned and suggested by you.
I appreciate your commitment and determination for this project.

I'm open to dissenting opinions in the matter, but I believe... "This is the way."

Thanks, @thelonelycoder

Ditto

 

[garycnew]

Just to clarify, is the “tailscale” version here the normal one for more recent routers and the “tailscale_nohf” version for armv7sf-k2.6 based devices such as the RT-AC68U?

@jksmurf

I found myself needing to know the answer to this question. It appears HF is for CPU's that support Hardware Floating Pointer calculations and NOHF is for CPU's that do not and preform the calculations by way of software.

As the armv7l CPU (`uname -m`) does not contain the term "fpu" within the `cat /proc/cpuinfo` output; thus, it makes use of NOHF (Software Floating Pointer) packages.

Hope that helps.

Regards,


Gary

 

[garycnew]

@thelonelycoder

I found a couple more examples of when dependency conflicts between the entware and garycnew repo's exist:

Installing libpcre (8.45-5) to root...
Downloading https://bin.entware.net/armv7sf-k2.6/libpcre_8.45-5_armv7-2.6.ipk

Installing libpcre2 (10.42-1) to root...
Downloading https://garycnew.github.io/Entware/armv7sf-k2.6/libpcre2_10.42-1_armv7-2.6.ipk

AND

Installing libsqlite3 (3410200-1) to root...
Downloading https://bin.entware.net/armv7sf-k2.6/libsqlite3_3410200-1_armv7-2.6.ipk

Installing libsqlite3 (3.49.1-2) to root...
Downloading https://garycnew.github.io/Entware/armv7sf-k2.6//libsqlite3_3.49.1-2_armv7-2.6.ipk

Most of the garycnew repo apps depend on libpcre2 (not libpcre) and the libsqlite3 versioning is such that entware thinks the old 3410200-1 is greater than 3.49.1-2 (which it is clearly not).

I manually removed the entware repo from my /opt/etc/opkgs.conf, made the garycnew repo the base repo, and it all seems to work.

Respectfully,


Gary

 

[jksmurf]

@jksmurf

I found myself needing to know the answer to this question. It appears HF is for CPU's that support Hardware Floating Pointer calculations and NOHF is for CPU's that do not and preform the calculations by way of software.

As the armv7l CPU (`uname -m`) does not contain the term "fpu" within the `cat /proc/cpuinfo` output; thus, it makes use of NOHF (Software Floating Pointer) packages.

Hope that helps.

Regards,


Gary

Very good, that's a nice concise explanation, much appreciated.

The sample size of users who will benefit from it may be very small, but maybe (and there are still a few) someone will just plonk Tailmon on an old RT-AC68U Router to bypass CGNAT or something and this is for them. Awesome job, thank you.

k.

 

[cmkelley]

Because I am committed to my projects. I see them as my hobby and generally enjoy further developing them.
And I use my own scripts on many ASUS routers and find pleasure seeing it in use.
amtm is also part of the firmware. When I was asked if it could be included by @RMerlin back then it was clear to me that my involvement here is long term.

Some move on to other hobbies, lose interest, have no longer time or are disgruntled about the sun shining squarely into their eyes.
You tell me.

That DANG SUN!!!

As one of the "developers" who disappeared for a while and am only occsionally seen here now, a lot happened in my life. Note that the scare quotes around "developers" only applies to myself, I would never call myself a developer. People such as yourself are true developers, I'm a mediocre script writer at best, on a good day. I assume, as dangerous as that may be, that most, if not all of the other developers write software as a day job. I do not.

So what happened? Some people very close to me died, some from Covid, some from cancer, one from just plain old age, and another I'm pretty sure was by their own hand. So much death in a very compressed period of time has been very hard on my mental health. Scribe was not the only thing that fell by the wayside, I went from regularly riding my bicycle 100 to 200 miles per week, and around 8,000 miles a year, to not touching it for months. My wife has developed some health problems that have placed a higher portion of maintianing our household on me. I've had poor to moderate success at getting back on my bicycle, and I'm going to be blunt, my health is more important, so the bicycle is my primary goal. I put on over 40 lbs and I've only managed to take 10 lbs off (sorry for the imperial units).

I don't write this expecting sympathy. Others I'm sure have expericed similar losses, and I do feel bad about more or less abandoning scribe. I'm glad it's been added to the AMTM-OSR repository, I hope people with more coding skill than I have will also have the time and motivation to improve it. I am eternally grateful that you, rmerlin, and others have continued to expand the capabilities of ASUS routers.

Peace.

 

[thelonelycoder]

I don't write this expecting sympathy. Others I'm sure have expericed similar losses, and I do feel bad about more or less abandoning scribe. I'm glad it's been added to the AMTM-OSR repository, I hope people with more coding skill than I have will also have the time and motivation to improve it. I am eternally grateful that you, rmerlin, and others have continued to expand the capabilities of ASUS routers.

You have my full sympathy and I feel with you for the loss and burden that suddenly came into your life.
We as the community are grateful for your presence, the script and interactions you've provided us. And I certainly hope we will see you around every now and then if you can give your bike a break.

Take care bud and look after yourself and your loved ones.

 

[SomeWhereOverTheRainBow]

@thelonelycoder I ran into an issue, attempting to use python's ssl (python3-openssl) module, with the armv7sf-k2.6 repo's, in that ssl appears to function properly with the entware and garycnew repos' python3-openssl packages, but doesn't seem to work with the maurer repo's python3-openssl package.

entware:

# python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 3.0.10 1 Aug 2023
# openssl version
OpenSSL 1.1.1w  11 Sep 2023

maurer:

# python -c "import ssl; print(ssl.OPENSSL_VERSION)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/lib/python3.11/ssl.py", line 100, in <module>
ImportError: /opt/lib/python3.11/lib-dynload/_ssl.cpython-311-arm-linux-gnueabi.so: symbol COMP_get_type, version OPENSSL_3.0.0 not defined in file libcrypto.so.3 with link time reference

garycnew:

# python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 3.0.14 4 Jun 2024
# openssl version
OpenSSL 1.1.1w  11 Sep 2023

I'm trying to understand whether it's strictly an issue with maurer's repo, an issue with mixed packages from the combination of armv7sf-k2.6 repo's, or something else.

If you could attempt to reproduce each case, I would be greatly appreciative.

Respectfully,


Gary

If you are building that version of openssl during runtime there may be a spot in there where you have to specify the openssl version which should be built to correctly achieve the desired results. Either that, or somewhere there is a broken link.

 

[sfx2000]

I found myself needing to know the answer to this question. It appears HF is for CPU's that support Hardware Floating Pointer calculations and NOHF is for CPU's that do not and preform the calculations by way of software.

As the armv7l CPU (`uname -m`) does not contain the term "fpu" within the `cat /proc/cpuinfo` output; thus, it makes use of NOHF (Software Floating Pointer) packages.

Cortex-A9, which is an ARMv7A platform, FP is an option - so one either builds for FP or not, there is no middle...

Going back in time - RT-AC68U and similar don't support FP or NEON

Check cpuinfo - for example - this is an armhf target..

processor    : 0
BogoMIPS    : 38.40
Features    : fp asimd evtstrm crc32 cpuid
CPU implementer    : 0x41
CPU architecture: 8
CPU variant    : 0x0
CPU part    : 0xd03
CPU revision    : 4

 

[sfx2000]

As one of the "developers" who disappeared for a while and am only occsionally seen here now, a lot happened in my life. Note that the scare quotes around "developers" only applies to myself, I would never call myself a developer. People such as yourself are true developers, I'm a mediocre script writer at best, on a good day. I assume, as dangerous as that may be, that most, if not all of the other developers write software as a day job. I do not.

Similar challenges with a cancer scare and other things all at the same time...

Work on your health - sound body/sound mind...

 

[SomeWhereOverTheRainBow]

Cortex-A9, which is an ARMv7A platform, FP is an option - so one either builds for FP or not, there is no middle...

Going back in time - RT-AC68U and similar don't support FP or NEON

Check cpuinfo - for example - this is an armhf target..

processor    : 0
BogoMIPS    : 38.40
Features    : fp asimd evtstrm crc32 cpuid
CPU implementer    : 0x41
CPU architecture: 8
CPU variant    : 0x0
CPU part    : 0xd03
CPU revision    : 4

I've used export CFLAGS="-O2 -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -ftree-vectorize" , but it was on a different setup than the RT-AC68U. My output is similar:

processor       : 0
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

and this is from the RT-AC68U:

Processor       : ARMv7 Processor rev 0 (v7l)
processor       : 0
BogoMIPS        : 2798.38

processor       : 1
BogoMIPS        : 2798.38

Features        : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0

Hardware        : Northstar Prototype
Revision        : 0000
Serial          : 0000000000000000

 

[garycnew]

If you are building that version of openssl during runtime there may be a spot in there where you have to specify the openssl version which should be built to correctly achieve the desired results. Either that, or somewhere there is a broken link.

@SomeWhereOverTheRainBow

I believe the "unexpected openssl version output" you're referring to was actually an issue with @maurer's armv7fs-k2.6 repository and one of the reasons I felt I needed to compile my own from scratch. Presently, garycnew's armv7fs-k2.6 repository is compiled with libopenssl_3.0.14-2 and doesn't appear to have any issues.