Hello!
I’m using resin-wifi-connect in two devices. One is a RPI3 and the other is a RPI0W. My aplication is a node app that I must trigger a push button to connect to the captive portal (basically it spawns a node process, calling a bash script. which then runs the src/app.js with --clear=true).
It works perfectly on RPI3. When the network is different it allows me to trigger the hardware button, and, minutes later I can see the ssid of the device, connect to it and change the network. It also works when it is already connected and I need to change to another wifi network.
But on RPI0W it does not work. After I “commented” some resource-hungry parts of the code, It began to work as before: when connected, triggering the button allows to change to another network. But when the network is different (when I took the device to another place, with another network), pressing the button does not work. The RPI0W just blink the led for four times and does nothing. Neither can I see any logs, because it displays as offline in Resin dashboard.
The part of the code base that handles the wifi is equal in both devices. Already did diff on all files and inspected system-connections on /boot partition of both devices to see if was a coding mistake or a network misconfiguration of mine, but it’s equal. The only differences is that on the RPI3 the programs (main and src/app.js) are compiled using pkg, and in the src/networkManager.coffee I included a ethernet connection in the whitelist. It was needed because The RPI3 is connected to another device using a fixed IP by ethernet, which I have to guarantee to not take priority over the wifi connection (it’s done with some rules on a file on /boot/system-connections).
After all those tests and lots of research I’m suspecting that the problem is on the supervisor version of the RPI0W, which is older than the RPI3:
RPI0W:
Supervisor Version
4.3.1
Host OS Version
Resin OS 2.0.6+rev3 (prod)
RPI3:
Supervisor Version
6.1.2
Resin OS 2.2.0+rev1 (prod)
Updating it might solve the problem? What do you guys think? I’m missing something here regarding resin-wifi-connect functionality or other stuff? Thanks a lot in advance!
Hi @arthurmoises
Do you see the same issue on the Pi Zero if you push the stock resin-wifi-connect app and trigger it over terminal/ssh?
If you have a serial cable I would advise flashing a dev image, connecting your serial cable to the Pi Zero and then debugging via that connection. This will allow you to trigger and view logs when the device is not connected to the internet and make use of the nmcli command line tool to see what Network Manager connections are present at each stage of the process.
Hi @joe
Thanks for the reply!
When I push the stock resin-wifi-connect app I get the “no introspectable” error, right on the first start script run. Then I fixed it by adding ENV INITSYSTEM on to Dockerfile.template and changing the variable START_SLEEP value from -1 to -30 in the start script.
After that, I managed to trigger the script with the --clear=true flag from the terminal, by creating and running an almost identical start script, the difference being the clear flag set to true. When I did that, I got the same “no introspectable” error as before:
sh chg-wifi.sh
Clear is enabled
Device type is raspberry-pi
{ Error: No introspectable
at /usr/src/app/node_modules/dbus/lib/bus.js:101:15
cause:
Error: No introspectable
at /usr/src/app/node_modules/dbus/lib/bus.js:101:15,
isOperational: true }
Exiting
Then I accessed the start script and modified the flag from false to true and ran it as bash start. Guess what? It worked! Weird. Then I commit another chg-wifi file but without the .sh extension, and ran it from terminal instead of the modified start file. It worked again! So it was the .sh extension the cause of the problem.
The last test involved adding the node code, the npm dependencies and Dockerfile.template programs, to make the project look equal the code that motivated this trouleshooting post, but changing how the script is called inside the node code, from spawn('bash chg-wifi.sh', { to spawn('bash chg-wifi', {. Result: I’m getting the “no instrospectable” error again. Then I issued the bash chg-wifi again (but this time with the node main script running) and got the same error of “no introspectable”. I’m thinking that running a node process is consuming to much processor power, because this kind of error didn’t happen on the Raspberry Pi 3. Also I’ll put the serial cable to see if I can debug some internal log.
Another test that I performed was killing the node process and running bash chg-wifi. It worked! So, I’ll try to call the change wifi script using another methods, that aren’t so processor hungry.
Thanks for your help!
@arthurmoises I am keen to see if using the rust implementation fixes these weird issues. I replied to your issue last night, can you try that and report back?