Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#3441 - Menuconfig misbehaviour: wpad-mesh-wolfssl disappears depending on wpad-basic state #8312

Open
openwrt-bot opened this issue Nov 10, 2020 · 8 comments
Labels

Comments

@openwrt-bot
Copy link

ilario:

====Premise:====

I am on OpenWrt 19.07.4 and menuconfig is behaving weirdly in a case.
I was trying to document how to select wpad-mesh-wolfssl and deselect wpad-basic for LibreMesh compilation and found something that looks like a bug in some Config.in file used by menuconfig.
Original bug reported on LibreMesh issues list here:
libremesh/libremesh.github.io#125

====Getting there:====

Selecting at the same time wpad-basic and wpad-mesh-wolfssl causes a clash of files installation in the compilation process. For this reason the deselection of wpad-basic has been suggested in LibreMesh compilation instructions.

wpad-mesh-wolfssl can be selected in menuconfig and wpad-basic deselected, until here everything ok.

====Issue:====

Then when closing and opening again menuconfig, wpad-mesh-wolfssl is not visible.

Screenshot: https://user-images.githubusercontent.com/1329018/98670652-4877ca80-2353-11eb-9d7f-96b5c5d718fd.png

But when wpad-basic (or something else) is selected, wpad-mesh-wolfssl appears and is actually selected (as it should be).

Screenshot: https://user-images.githubusercontent.com/1329018/98670749-7230f180-2353-11eb-9d44-2d6a9bcb3c78.png

The wpad-mesh-wolfssl package is categorized as being inside wpad-mesh-openssl, which makes no sense.

Screenshot: https://user-images.githubusercontent.com/1329018/98670837-9b518200-2353-11eb-8cf0-f490182b4ee2.png

And all of this happens even if the definitions of wpad-basic, wpad-mesh-openssl and wpad-mesh-wolfssl are substantially identical (extracted from https://github.com/openwrt/openwrt/blob/openwrt-19.07/package/network/services/hostapd/Makefile ):

wpad-basic
[identical part removed]
VARIANT:=wpad-basic

wpad-mesh-openssl
[identical part removed]
DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
PROVIDES+=wpa-supplicant-mesh wpad-mesh
DEPENDS+=+libopenssl
VARIANT:=wpad-mesh-openssl

wpad-mesh-wolfssl
[identical part removed]
DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
PROVIDES+=wpa-supplicant-mesh wpad-mesh
DEPENDS+=+libwolfssl
VARIANT:=wpad-mesh-wolfssl

This looks like a bug in some of the Config.in files used by make menuconfig.
Just to support this, I exchanged the order in which wpad-mesh-openssl and wpad-mesh-wolfssl are defined in tmp/.config-package.in and now wpad-mesh-wolfssl and wpad-mesh-openssl are at the same hierarchical level. There's clearly a bug around.

Thanks!

@openwrt-bot
Copy link
Author

ilario:

Additional scenario that makes this issue more annoying:

  • open menuconfig
  • select wpad-mesh-wolfssl and deselect wpad-basic
  • close and save
  • my .config is like this: http://sprunge.us/3fE1sU
  • open menuconfig
  • close and save
  • my .config changed and wpad-mesh-wolfssl is not selected anymore, see it here: http://sprunge.us/FGQgeY

This means that every time I modify something in the menuconfig, I have to select again the wpad-mesh-wolfssl package.

@openwrt-bot
Copy link
Author

ilario:

In order to understand something I did a traceback, I report it here more as a note to myself:

menuconfig uses mconf

mconf represents the data from "tmp/.config-package.in"
here there's in wpad-mesh-wolfssl a line that does not have an equivalent in wpad-mesh-openssl

depends on m || (PACKAGE_wpad-mesh-openssl != y)

"tmp/.configure-package.in" gets generated by "scripts/package-metadata.pl config"

"scripts/package-metadata.pl config" takes the info from "tmp/.packageinfo"

here the wpad-mesh-wolfssl has wpad-mesh-openssl mentioned between the conflicts, but the opposite does not happen

"tmp/.packageinfo" gets generated by "include/scan.mk"

"include/scan.mk" gets invokated by "include/toplevel.mk" with (in case it was useful for easing the troubleshooting):

TOPDIR=$(pwd) make -j1 -r -s -f include/scan.mk SCAN_TARGET="packageinfo" SCAN_DIR="package" SCAN_NAME="package" SCAN_DEPTH=5 SCAN_EXTRA=""

"include/scan.mk" merges many files from "tmp/info/", the interesting one is ".packageinfo-network_services_hostapd"
here the same aforementioned "Conflicts:" entry appears

the "tmp/info/.packageinfo-network_services_hostapd" is also generated by the scan.mk call

"include/scan.mk" calls make in plenty of directories, between which also "package/network/services/hostapd"

TOPDIR=$(pwd) INCLUDE_DIR=$(pwd)/include make V=ss --no-print-dir -r DUMP=1 FEED="" -C package/network/services/hostapd

and this creates the Conflicts list from the $CONFLICTS variable set inside "package/network/services/hostapd/Makefile" so that after a few hours of looking into the issue turns out that the issue was in the most logical place.

The lists

SUPPLICANT_PROVIDERS:=
HOSTAPD_PROVIDERS:=

gets populated as the things get defined across the Makefile, so that at the moment of defining wpad-mesh-openssl, these variables do not contain any wpad-mesh-*. At this point, wpad-mesh-openssl gets added there.
For this reason, when wpad-mesh-wolfssl gets defined these lists already contain wpad-mesh-openssl.

This means that each package has a non-complete conflicting packages list depending on when it gets defined inside the Makefile.

@openwrt-bot
Copy link
Author

ilario:

And when running the menuconfig thereś also a funny message stating:

tmp/.config-package.in:139918:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
tmp/.config-package.in:139918: symbol PACKAGE_wpad-mesh-wolfssl is selected by PACKAGE_wpad-mesh-wolfssl

@aparcar aparcar added the release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release label Feb 22, 2022
@ilario
Copy link
Contributor

ilario commented Mar 7, 2022

Thanks @openwrt-bot!
@aparcar do you know if this is fixed in 21.02?

@aparcar
Copy link
Member

aparcar commented Mar 7, 2022

Inverting the order of openssl and wolfssl (aka wolfssl first) fixes the subcategory issues. Not sure what's the base for that.

Overall wired that we have wpad and wpad-basic but not wpad-mesh.

@nbd168 ideas for this?

@aparcar aparcar removed the release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release label Mar 7, 2022
@ilario
Copy link
Contributor

ilario commented Jul 13, 2022

With OpenWrt 22.03.0-rc4 is even worse as I cannot manage to deselect wpad-basic-wolfssl (even if in menuconfig it looks like I managed to deselect it, it is still active in .config),

@ilario
Copy link
Contributor

ilario commented Apr 5, 2023

I am still having problems with this on v22.03.3.
To reproduce:
create a .config file with only this line:

CONFIG_PACKAGE_wpad-openssl=y

run make defconfig

check the content of the .config file. You will find something like this:

$ grep -i wpad .config
CONFIG_DEFAULT_wpad-basic-wolfssl=y
# CONFIG_PACKAGE_wpad is not set
# CONFIG_PACKAGE_wpad-basic is not set
# CONFIG_PACKAGE_wpad-basic-openssl is not set
CONFIG_PACKAGE_wpad-basic-wolfssl=y
# CONFIG_PACKAGE_wpad-mesh-openssl is not set
# CONFIG_PACKAGE_wpad-mesh-wolfssl is not set
# CONFIG_PACKAGE_wpad-mini is not set
CONFIG_PACKAGE_wpad-openssl=m
# CONFIG_PACKAGE_wpad-wolfssl is not set

as you can see, wpad-openssl has been deselected and wpad-basic-wolfssl has been selected.

Is there a way for having the full wpad-openssl compiled in the firmware using the buildroot?

@ilario
Copy link
Contributor

ilario commented Apr 5, 2023

Selecting a package with a dependency from wpad-openssl (this package: https://github.com/libremesh/network-profiles/blob/master/calafou/outdoor-crypt/Makefile ) seems that managed to keep wpad-openssl selected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants