WiFi qui ne se connecte pas

Bonjour,

J’ai un rpi4 qui tourne à merveille sur jeedom. Néanmoins, même apres plusieurs résinstallations, le meme problème revient : je n’arrive pas à faire fonctionner le wifi. Impossible à faire connecter wlan0 sur une hotspot, alors que ce même pi y arrivait parfaitement auparavant.

En effet, lorsque je pars d’une image buster, tout fonctionne, jusqu’au moment où j’installe et configure deux choses :

  • jeedom
  • modemmanager + network manager
    Ce pi est connecté à internet via une Huawei 3372, dont la connexion est automatisée par network-manager. Je soupconne que le problème vienne de ce second point.

Je tourne en rond, j’ai essayé de modifier interfaces, dhcpcd.conf, wpa_supplicant (qui est bien configuré), le fichier config de networkmanager… Bref, si quelqu’un aurait des lumières, je suis preneur d’un coup de pouce…

ip link list wlan0
3: wlan0: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether de:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

nmcli

wlan0: unavailable
	"Broadcom BCM43438 combo and Bluetooth Low Energy"
	wifi (brcmfmac), DE:7xx:xx:xx:xx:xx, hw, mtu 1500

sudo iwlist wlan0 scan | grep -i ssid
ESSID: " hotspot"

iwlist wlan0 scan

wlan0     Scan completed :
          Cell 01 - Address: xx:xx:xx:xx:xx:xx
                    Channel:11
                    Frequency:2.462 GHz (Channel 11)
                    Quality=52/70  Signal level=-58 dBm
                    Encryption key:on
                    ESSID:"hotspot"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s
                    Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
                    Mode:Master
                    Extra:tsf=0000000000000000
                    Extra: Last beacon: 15730ms ago
                    IE: Unknown: 000D416E64726F6964415044313035
                    IE: Unknown: 010882848B0C12961824
                    IE: Unknown: 32043048606C
                    IE: Unknown: 03010B
                    IE: Unknown: 050401020000
                    IE: Unknown: 2A0104
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : CCMP
                        Pairwise Ciphers (1) : CCMP
                        Authentication Suites (1) : PSK
                    IE: Unknown: 2D1A2D0117FF00000000000000000000000000000000000000000000
                    IE: Unknown: 3D160B000400000000000000000000000000000000000000
                    IE: Unknown: DD180050F2020101000003A4000027A4000042435E0062322F00
                    IE: Unknown: DD050016328000
                    IE: Unknown: DD080050F21102000000

iwconfig

wlan0     IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

Contenu du fichier « interfaces » :

# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

Contenu du fichier dhcpcd.conf

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
#
interface eth0
static ip_address=192.168.1.36/24
static routers=192.168.1.250
static domain_name_servers=192.168.1.250

#denyinteraces wlan0
interface wlan0
noipv6

(Comme vous pouvez le voir, j’ai déjà fait pas mal d’essais ici, mais meme en remettant le fichier par défaut, cela ne change rien)

Contenu du fichier wpa_supplicant.conf

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=FR

network={
	ssid="wifi"
	psk=xxx
	priority=5
}

network={
	ssid="hotspot"
	psk=xxx
	priority=1
}

contenu du fichier /etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile
dhcp=internal

[ifupdown]
managed=false

(Idem, j’avais fait des essais ici…)

Il semblerait que la carte voit bien les wifi, mais que le wlan0 reste tout le temps « DOWN », meme quand j’essaie de le forcer en UP. Merci de vos éventuels conseils.

Hello

Donc tu installe raspi-os et ensuite jeedom ?

Si oui pourquoi tu installe pas direct l’image jeedom
https://images.jeedom.com/rpi/

As tu essayé avec une autre alim pour ton rpi , au même moment as tu connecté des clefs usb sur ton pi ?
Si oui enlève les , et fais des tests sans rien de connecté en usb

Merci des idées

Oui en effet c’est pi OS puis ensuite j’installe jeedom. Par contre ce jeedom est en opérationnel et je ne peux pas me permettre de tout réinstaller facilement, ça va faire trop juste en temps / risqué. Par contre clairement j’avais testé le WiFi, signe que le wpa_supplicant était bien configuré…

J’ai une alim bien surdimensionnée, que j’avais déjà d’ailleurs changé en préventif : alim rail DIN meanwell mais en 6A ! Voltage réglé a 5.13V.

Je vais essayer de débrancher le modem USB, mais j’avoue être très perplexe sur la cause de ce problème ! C’est également un SSD en USB, celui là on ne va pas débrancher :slight_smile:

Merci des pistes, je test davantage cet après midi !

Re

Ca que tu peux faire
Backup de jeedom

Nouvelle install de jeedom via le lien

Tu réinjecte ta backup. en croisant les doigts que d’autre bug ne survienne pas .

PS: tu veux contrôlé jeedom en wifi ?

Hello

Ca marche. Je voulais autant que possible éviter de modifier l’installation existante, car tout était bien configuré, mais à défaut d’explication ça peut etre un bon moyen de tester.

En fait le pi repose sur une clé 4G pour communiquer (pas d’internet ADSL/Fibre) ; l’installation dispose également d’une clé ZWave et d’un « modem » pour le linky. Le tunnel jeedom me permet de me connecter à distance, même sans IP fixe (clé 4G), par contre aucune possibilité de SSH. Un wifi qui fonctionne me permettrait de me connecter en SSH avec mon téléphone quand je suis sur place : actuellement je suis obligé de tirer un RJ45 et donc d’amener un PC portable… Pas idéal :slight_smile:

Pas encore eu le temps, mais je vais tester de débrancher la clé 4G, refaire un essai, puis sinon tester avec l’imager buster. J’ai bien peur que le problème ne se reproduise dès que je reconfiguerai nmcli pour autoconnecter la clé 4G, mais on verra…

Merci en tout cas des conseils.

Bon, je suis parti d’une installation propre image jeedom, sans configurer la clé 4G.
J’ai juste fait les manip du raspi-config pour configurer la localisation, le wifi, et modifié le dhcpcd.conf pour avoir une eth0 fixe.

3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether e4:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

Ne veut rien savoir. Je ne comprends pas.

J’ai un problème similaire, plus de wifi depuis que j’utilise un disque SSD sur usb3. C’est un problème apparemment connu d’interférences entre l’usb3 et le wifi 2.4ghz.

1 « J'aime »

Roh punaise… Je pouvais toujours chercher :frowning: C’est étrange tout de même. Et aucun fix possible? C’est lié au controlleur SSD sur le pi, et non aux éventuelles interférences du SSD lui-même? (Donc déporter le SSD ne changerait rien?)

Merci de ton retour, c’est sympa.

Pas trouvé de fix, à part passer le SSD sur de l’usb2, mais c’est dommage. Je n’ai qu’un seul système, en production, donc j’attends la fin de la saison de chauffe pour tester d’autres configurations.

OK merci.
Mes 4 ports USB sont en utilisation, donc en gros, il faudrait passer par un hub connecté en USB2 si je veux éviter cela? Ca pourrait faire un USB2 pour le SSD, le second pour le hub (et donc les 3 autres ports USB dessus : telelink, z-wave, et clé 4G).

Dans l’absolu, je suis mitigé d’ajouter un hub (encore une « couche » qui peut déconner) et brider le SSD, je vais peut etre me contenter du RJ45 et du laptop en attendant. Si tu trouves une autre astuce ou solution, je suis preneur.

Un grand merci à toi pour le partage, j’aurais pu continuer à chercher longtemps :slight_smile:

Bonsoir.

Commencez par tester ainsi.

Placez le disque sur un port usb2 et rien d’autre sur le Raspberry.

Vous serez vite fixé.

Et si cela ne fonctionne pas, utiliser un autre fichier de configuration wifi, il existe plusieurs types en fonction du chiffrement.