Python error when running LXMD
F4HVO opened this issue ยท 8 comments
Thank you for your project it is very interesting !
Beginner here so there is certainly an issue with my configuration.
I am trying to setup a propagation node on a linux computer, using a LORA module, when I run LXMD I have a suspicious warning and then error messages every 5 seconds. Also, I am not able to confirm that propagation/message retention works (I can see the propagation node from another node, I have a few messages "On Propagation Net", sent from another node, through sideband, but when I open nomadenet from the propagation node, these messages never change status and never appear in my inbox)).
Suspicious message is :
[2023-01-27 14:13:00] [Warning] Clint authentication was enabled, but no identity hashes could be loaded from /home/hugo/.lxmd/allowed. Nobody will be able to sync messages from this propagation node.
This is suspicious because LXMD configuration contains auth_required = no
.
Edit : after reading the code, it might be a false warning, from lxmd.py:325, the number of allowed entities is checked wether the auth_required is True or False.
Errors are :
[2023-01-27 14:13:10] [Error] An error occurred while running periodic jobs. The contained exception was: unsupported operand type(s) for +: 'float' and 'NoneType'
Edit : this error is due to the fact that the following line was commented : announce_interval = 360
under [lxmf] in the LXMD configuration file.
My configuration is the following :
LXMD
# This is an example LXM Daemon config file.
# You should probably edit it to suit your
# intended usage.
[propagation]
# Whether to enable propagation node
enable_node = true
# Automatic announce interval in minutes.
# 6 hours by default.
announce_interval = 360
# Whether to announce when the node starts.
announce_at_start = yes
# Wheter to automatically peer with other
# propagation nodes on the network.
autopeer = yes
# The maximum peering depth (in hops) for
# automatically peered nodes.
autopeer_maxdepth = 4
# By default, any destination is allowed to
# connect and download messages, but you can
# optionally restrict this. If you enable
# authentication, you must provide a list of
# allowed identity hashes in the a file named
# "allowed" in the lxmd config directory.
auth_required = no
[lxmf]
# The LXM Daemon will create an LXMF destination
# that it can receive messages on. This option sets
# the announced display name for this destination.
display_name = My Node
# It is possible to announce the internal LXMF
# destination when the LXM Daemon starts up.
announce_at_start = yes
[logging]
loglevel = 4
Reticulum
# This is the default Reticulum config file.
# You should probably edit it to include any additional,
# interfaces and settings you might need.
# Only the most basic options are included in this default
# configuration. To see a more verbose, and much longer,
# configuration example, you can run the command:
# rnsd --exampleconfig
[reticulum]
# If you enable Transport, your system will route traffic
# for other peers, pass announces and serve path requests.
# This should only be done for systems that are suited to
# act as transport nodes, ie. if they are stationary and
# always-on. This directive is optional and can be removed
# for brevity.
enable_transport = True
# By default, the first program to launch the Reticulum
# Network Stack will create a shared instance, that other
# programs can communicate with. Only the shared instance
# opens all the configured interfaces directly, and other
# local programs communicate with the shared instance over
# a local socket. This is completely transparent to the
# user, and should generally be turned on. This directive
# is optional and can be removed for brevity.
share_instance = Yes
# If you want to run multiple *different* shared instances
# on the same system, you will need to specify different
# shared instance ports for each. The defaults are given
# below, and again, these options can be left out if you
# don't need them.
shared_instance_port = 37428
instance_control_port = 37429
# You can configure Reticulum to panic and forcibly close
# if an unrecoverable interface error occurs, such as the
# hardware device for an interface disappearing. This is
# an optional directive, and can be left out for brevity.
# This behaviour is disabled by default.
panic_on_interface_error = No
[logging]
# Valid log levels are 0 through 7:
# 0: Log only critical information
# 1: Log errors and lower log levels
# 2: Log warnings and lower log levels
# 3: Log notices and lower log levels
# 4: Log info and lower (this is the default)
# 5: Verbose logging
# 6: Debug logging
# 7: Extreme logging
loglevel = 4
# The interfaces section defines the physical and virtual
# interfaces Reticulum will use to communicate on. This
# section will contain examples for a variety of interface
# types. You can modify these or use them as a basis for
# your own config, or simply remove the unused ones.
[interfaces]
# This interface enables communication with other
# link-local Reticulum nodes over UDP. It does not
# need any functional IP infrastructure like routers
# or DHCP servers, but will require that at least link-
# local IPv6 is enabled in your operating system, which
# should be enabled by default in almost any OS. See
# the Reticulum Manual for more configuration options.
[[Default Interface]]
type = AutoInterface
enabled = Yes
enable_node = Yes
[[RNode LoRa Interface]]
type = RNodeInterface
enabled = Yes
enable_node = Yes
node_name = sdr
announce_at_start = Yes
announce_interval = 360
port = /dev/ttyACM0
frequency = 433920000
bandwidth = 125000
txpower = 7
spreadingfactor = 8
codingrate = 5
Thank you very much for discovering these errors and for your detailed report, which made it a breeze to fix.
You're right, it's a false warning that actually doesn't affect functionality, but it should of course still not behave like that :)
Aditionally, as you correctly diagnosed, there was a missing check when the announce intervals were unset.
I'll be pushing a fix in a moment.
I will just be transferring this issue to the LXMF repository.
Packages incoming :)
You are very wellcome and thank you for your amazing reactivity. Also if you could point me in the right direction,
I am trying to send a message between two users, one of them beeing not connected at the time of the message sending.
I assume that if at least one node runs lxmd, this node would do the buffering untill the destination user 'connects' to the node (here using nomadenet).
At the moment, I can send direct message and propagated messages when both user are on the network but not when one is disconnected (no new messages when reconnecting).
Maybe I should post this in the discussion section sorry for the noise.
You are very wellcome and thank you for your amazing reactivity.
Thank you! Really appreciate the useful bug report :)
I am trying to send a message between two users, one of them beeing not connected at the time of the message sending.
I'd love to give you a detailed answer to this question, but if you don't mind, please post it in th discussions section, since other users with the same question can then easily benefit from it too. That's especially useful now when there is so little documentation on LXMF :)
An updated lxmf
package with the fixes included, version number 0.3.0
, is available in the repositories now. Just run pip install lxmf --upgrade
to get it.
Allright ! I no longer have these messages !
I created this discussion regarding my previous question.
Good to hear! Thanks for reporting it back.
Great, I posted an answer to your question there.