`--export-config` fails silently

[fatchild]

When I use --export-config in the form below, it fails silently. The error which I would expect in STDERR is redirected as STDOUT to the file.

meshtastic --export-config > config_backup.yaml

I think it would be an improvement to have warnings and errors printed to STDERR.

[SpudGunMan]

See discord #python notes on this.

The issue likely lies in a function for canned messages which gets called and may not timeout correctly

[juergenRe]

@fatchild: Could you please upload the yaml or give other hints where the error exactly occurs? We should fix the export problem.

According to the help you should instead use: meshtastic --export-config config_backup.yaml
(Without redirection of stdout at all). Then you will get the errors on the terminal.

[SpudGunMan]

[juergenRe]

Thats your assumption. I am not sure if it is correct: I was playing around with the canned messages a bit and it worked fine in the export/config cases with FW 2.611 and CLI 2.7.3 on a Heltec. So there must be more.

From what I saw here, people are quite often posting an issue without mentioning the used versions, posting an --info etc. So it becomes difficult to understand whats going on.

[segarza]

I'm experiencing a similar issue on a Lilygo T-Deck. CLI 2.7.5 and firmware 2.7.15.567b8ea Beta. The python client app just hangs when attempting to do a --export-config. Performing a --info works fine. Tried a full erase and install and I'm experiencing the same hanging behavior.

[juergenRe]

@segarza: what I can see from your log is that the CLI never gets in the state "connected". The loading of all configs finishes correctly, the config complete routine gets called. Inside there are 2 functions called: one for setting the channels for the local node data and then, second, sending a heartbeat.

When calling the heartbeat, there should appear another log entry, which is missing here. Anyway, when the CLI does not enter the connected state, the exporting of the configuration data never starts.

But, for the --info this part is exactly the same - why does it work there and not for the --export-config? You are sure you captured the full log? And you are sure also, that the CLI "hangs", so to return to the command line you need to enter "Ctrl-C" or something similar?

You see, I am a bit confused and try to ensure my understanding.

Could you please try to upload you debug log as a file instead of pasting it directly? Scrolling between the messages gets easier when the they are shorter. Thank you.

[segarza]

@juergenRe Here are the debug logs for both the info (successful) and export-config (unsuccessful). I had to interrupt the export-config with ^C as it never finished and just hanged. I piped both stdout and stderr to the logs when executing the meshtastic app. Redacted private keys.

export-config_redacted.log
info_redacted.log

[juergenRe]

@segarza : Great, thanks a lot for these additional infos! Now the log gets further and I can see the program enters the part in retrieving the infos for the export.

However, it gets stuck in getting the canned messages, so the problem might be related to what spudgunman described above.

The reason why it gets stuck is, that the radio does not send any response. On the client side, no time-out is implemented - so you will wait forever. So we have 2 problems here:

1. The radio does not respond to the request with the expected message ID. No clue why, but it happened to me also on other commands, evtl. dependingon the current charge of the radio. Distance is not an issue when you connect directly.
2. The client does not handle such cases. In reality, it always possible that a packet gets lost, especially when you are connected via a wireless protocol.

If have been quickly checking the code if it is much effort to add a timeout for this case. Unfortunately this is much effort, because the responsabilities between node and meshinterface are mixed and not clearly shared (both classes implement sending of data). meshinterface implements a time-out, whereas node does not or in a different way. Need to have closer look here before doing a change.