First, if you use WiFi, could you disable Ethernet? There is a known issue when having both enabled but connected to different subnets: https://github.com/MichaIng/DietPi/issues/2103
In such cases a route table is required so the systemd knows which request to send to which network interface.
Aside from that, I personally never tried to connect to hidden SSIDs with DietPi, but AFAIK if the dietpi-wifi.txt entries match, it should not play a role. Only SSID scanning via dietpi-config of course will not lead to a result. However I will try to replicate it here if I find time tomorrow to see if there is really something special needed for hidden SSIDs.
Could you try to add ap_scan=2
to the top of /etc/wpa_supplicant/wpa_suplicant.conf
? I read in some search results that this can be required to catch hidden SSIDs.
About this setting from an example config file:
# AP scanning/selection
# By default, wpa_supplicant requests driver to perform AP scanning and then
# uses the scan results to select a suitable AP. Another alternative is to
# allow the driver to take care of AP scanning and selection and use
# wpa_supplicant just to process EAPOL frames based on IEEE 802.11 association
# information from the driver.
# 1: wpa_supplicant initiates scanning and AP selection; if no APs matching to
# the currently enabled networks are found, a new network (IBSS or AP mode
# operation) may be initialized (if configured) (default)
# 0: driver takes care of scanning, AP selection, and IEEE 802.11 association
# parameters (e.g., WPA IE generation); this mode can also be used with
# non-WPA drivers when using IEEE 802.1X mode; do not try to associate with
# APs (i.e., external program needs to control association). This mode must
# also be used when using wired Ethernet drivers (including MACsec).
# 2: like 0, but associate with APs using security policy and SSID (but not
# BSSID); this can be used, e.g., with ndiswrapper and NDIS drivers to
# enable operation with hidden SSIDs and optimized roaming; in this mode,
# the network blocks in the configuration file are tried one by one until
# the driver reports successful association; each network block should have
# explicit security policy (i.e., only one option in the lists) for
# key_mgmt, pairwise, group, proto variables
# Note: ap_scan=2 should not be used with the nl80211 driver interface (the
# current Linux interface). ap_scan=1 is optimized work working with nl80211.
# For finding networks using hidden SSID, scan_ssid=1 in the network block can
# be used with nl80211.
# When using IBSS or AP mode, ap_scan=2 mode can force the new network to be
# created immediately regardless of scan results. ap_scan=1 mode will first try
# to scan for existing networks and only if no matches with the enabled
# networks are found, a new IBSS or AP mode network is created.