Mesh Chat has been in a difficult state since October 2024. It would not operate in AREDN nodes with any firmware release after 3.24.10.0. Mesh Chat 2.12.1 in a node with a nightly build would not sync with Mesh Chat in other nodes.
KN6PLV remedied this situation about 2025-02-07 by publishing new Mesh Chat releases. I have his meshchat_2.13_all.ipk running in a hAP ac2 and meshchat-api_2.13_all.ipk running in a hAP ac lite with an RPi 5 service computer with meshchat_1.02. Both 2.13 nodes synchronize with several other Mesh Chat 2.12.1 services on our mesh island.
The new Mesh Chat apps are available at https://github.com/kn6plv/meshchat . Click the version that you want, then click the download button near the right end of the bar labeled CODE. It appears that you need to be running a current nightly build (after NB 20250207) in your node for the new Mesh Chat to work. For me, the new versions picked up the previous-messages log as if nothing had changed.
A tip of my hat and many thanks to KN6PLV for this accomplishment.
I noticed that installing the new package actually installed three packages, not just the one. Is there anything related to other packages affected by these changes?
Ed
Ed -
If you go to your node's Status screen, click to the right of the installed packages area, then click the view button to the right of the "Remove Package" field, you will see names of your meshchat app and two other packages which are necessary for meshchat to run. I think these were no longer provided in the nightly builds. To clear, just click "Done" in the lower right without selecting any package.
Tim K5RA
Downloading http://downloads.arednmesh.org/releases/3/24/3.25.2.0/targets/ath79/mikr...
Failed to send request: Operation not permitted
Failed to send request: Operation not permitted
Failed to send request: Operation not permitted
Failed to send request: Operation not permitted
Failed to send request: Operation not permitted
*** Failed to download the package list from http://downloads.arednmesh.org/releases/3/24/3.25.2.0/targets/ath79/mikr...
Downloading http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
*** Failed to download the package list from http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
Downloading http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
*** Failed to download the package list from http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
Downloading http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
*** Failed to download the package list from http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
Downloading http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
*** Failed to download the package list from Failed to send request: Operation not permitted
Failed to send request: Operation not permitted
Collected errors:
* opkg_download: Failed to download http://downloads.arednmesh.org/releases/3/24/3.25.2.0/targets/ath79/mikr..., wget returned 4.
* opkg_download: Check your network settings and connectivity.
* opkg_download: Failed to download http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc..., wget returned 4.
* opkg_download: Check your network settings and connectivity.
* opkg_download: Failed to download http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc..., wget returned 4.
* opkg_download: Check your network settings and connectivity.
* opkg_download: Failed to download http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc..., wget returned 4.
* opkg_download: Check your network settings and connectivity.
* opkg_download: Failed to download http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc..., wget returned 4.
* opkg_download: Check your network settings and connectivity.
* opkg_download: Failed to download http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc..., wget returned 4.
* opkg_download: Check your network settings and connectivity.
* opkg_download: Failed to download http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc..., wget returned 4.
* opkg_download: Check your network settings and connectivity.
http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
Downloading http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
*** Failed to download the package list from http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
Downloading http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
*** Failed to download the package list from http://downloads.arednmesh.org/releases/3/24/3.25.2.0/packages/mips_24kc...
The node I can't get to work is an SXT5 HP. It's running 3.25.2.0. Weird thing is when I attempted (again) to install 2.13.0 it did not give me the error messages, but when done and rebooted the node reports it has package 2.12.1 installed. The two extra packages are not in place.
I'll leave everything on other nodes un updated for a while until this is resolved.
Ed
I have put Meshchat_2.13 and Meshchat-api_2.13 in three Mikrotik nodes (two hAP ac Lites and one hAP ac2) with no issues.
Since the two support packages are not in your node, I think your attempt to load 2.13 was not successful. Meshchat_2.13 does work for several of us here running 3.25.2.0 and later nightly builds., so have confidence.
I suggest you uninstall whatever Meshchat and supporting packages you have in one or more of the nodes. Reboot. Get a copy of Meshchat_2.13 in your service computer. Install stable release 3.25.2.0 in the node(s), and ensure that it is (they are) working.
Then use the package install function in the (each) node to bring Meshchat_2.13 to the node(s). Next you will have to advertise your Meshchat service in each node with the name of the Meshchat zone that you and your fellow operators will use. Reboot. I think this causes creation of chat and file directories in the node. The Meshchat zone name should appear in your node's Local Services pane. There may be service names like Meshchat-8792. Delete those. Click your service announcement. Enter your call sign in the Chat box. You should be good from there.
For now I've rolled everything I can back to 3.24.10.0 and everything installs fine including MC2.13 so I'm leaving 3.25.2.0 alone until I get more definitive information. I've lost control of one remote node rolling the firmware back so I'll have to revisit it and do a fresh install. None of this addresses the simultaneous loss of use of Waterfall when switching to 3.25.2.0 so there is something in the new release that does not play well with packages.
Ed
I installed 3.25.2 and the pkg file, I see 3 pkgs when listing pkgs to remove.
So I went on to install 3.24.10 directly without removing pkgs.
Meshchat works!
Then I installed 3.25.2 on top, and Meshchat still works.
So now I am confused but happy :-)
will try again on some radio nodes like the Nanobeam's
Frank
I looked at your info above, and it looks like the error messages were from 3.25.2.0, not from attempt to install Meshchat. Meshchat is not sourced from AREDN. Go to
https://github.com/kn6plv/meshchat
You will see the names of the two versions of Meshchat slightly left and slightly below center of the screen. Click the one you want. Look on the right edge of the screen somewhat above the middle and see a symbol with a down-pointing arrow (for download). Click that, and a copy of the code you selected will come to you.
Good luck!
--Tim K5RA
The limitations of Meshchat being well-known, is there an established alternative? The closest I've gotten is Mumble. It works for VOIP and also has text chat. It's alot easier to install than a phone switch and is part of most linux distributions.
Orv W6BI
Is Mattermost still free? I don't see it as part of the Fedora distribution.
I've tried jabber, it wasn't too bad to install. I don't think there's a simple-to-install IRC server, I don't want to set up a separate MariaDB or LDAP server.
Mumble has some advantages: It's a very lightweight install, is built for all major distributions, and requires almost no configuration. Default mode is a default group chat and group VOIP. It doesn't require authentication by default, and authentication can be set up without a central authentication server (you hand out certificates instead.)
I've got a mumble server running at kf6iiu-services.local.mesh if anyone wants to see if they can connect to it. The IP address is 10.21.75.107 if the DNS isn't propagating.
73
Orv W6BI
- Rocket.Chat: While Rocket.Chat offers end-to-end encryption (E2EE), it is not enabled by default and is currently in beta. Users must manually enable it in their workspace settings .
- Mattermost: Mattermost uses encryption-in-transit (TLS) and encryption-at-rest but does not provide end-to-end encryption by default. It focuses on securing data between clients and servers rather than encrypting messages end-to-en
- Microsoft Teams: Microsoft Teams encrypts data in transit and at rest using TLS and SRTP, but it does not provide end-to-end encryption for all communications by default. However, it does offer end-to-end encryption for certain types of calls
- Flock: Flock encrypts all traffic between clients and servers using TLS but does not provide end-to-end encryption by default
- Lark: Lark encrypts data in transit using HTTPS/WSS but does not explicitly mention end-to-end encryption as a default feature
- Pumble: Pumble encrypts data in transit and at rest by default but does not specify if it offers end-to-end encryption
- Chanty: Chanty does offer end-to-end encryption for messages and files, making it one of the platforms that mandates encryption for sensitive data
Orv W6BII've been interested in other chat programs, and might implement others at some time. However the real attraction of MeshChat for me is that it can be hosted on the node itself, and does not require a server/client relationship on a Pi or an X86 machine. This allows us to have the message database be redundantly protected. We assume parts of our network will go down in a disaster so we want a resilient app and MeshChat does that easily.
It has been challenging to keep it going but TIm has been working on updates. So long as the patches work we will continue to use it. FWIW all the coms packages including Winlink have continuous maintenance required as browsers, OS, and hardware continues to change.
Ed
There are two kinds of MeshChat:
Each AREDN node version depends upon which release range of AREDN node firmware.
Of course the Debian (Linux) version(s) do not run on AREDN nodes.
Of course the perl and lua versions written for AREDN nodes do not run on Linux.
You will need an appropriate meshchat-api.ipk installed on the AREDN node hosting the meshchat service.
I think the appropriate meshchat-api will resolve all (lua) dependencies on the node hosting the meshchat service.
73, Chuck
If you use the api version, you will have to install Meshchat_1.02 in your service computer and set up the configuration file and service announcement. All that is much easier now than it was just a few years ago.
If you will provide an e-mail, I can send you the procedure that we used to use which may be helpful.
--Tim K5RA
I still fail to see how the dependencies on Luci are fulfilled in a non-Openwrt based distribution, so I'm eager to see what you did. There are various repos on github. The repo at https://github.com/hickey/meshchat says "Installable on AREDN firmware and most any Linux distribution" but then says "The current distribution of MeshChat does not currently support Linux. In order to run MeshChat on a Linux machine, one needs to download MeshChat v1.0.2 and install it on the Linux machine" - this makes no sense to me.
Some of the repos say there was a Perl version at one time but I haven't been able to find it.
I just want to get a server running. Since the REST interface is documented I can just write my own client rather than bother with all the Lua client stuff. I suppose I could use the REST interface to connect to someone else's meshchat daemon/ service/whatever it is.
Wiley -
There are at least three versions of Meshchat. The first was written by Trevor Paskett K7FPV in Perl. I think the last Perl version was Meshchat_1.02. I believe that Meshchat_1.02 and current AREDN firmware are not compatible. Then there was an AREDN developer team version which used LUA. Then Gerard Hickey WT0F took it over, and brought it to release 2.12.2. Last October, there were changes in AREDN firmware that removed LUA files needed by Meshchat, and Meshchat would not longer work with latest stable releases and Nightly Builds. This was fixed in February 2025 by KN6PLV. He was able to make changes to a Meshchat code base that he had, then build it and test it. The result was Meshchat-api_2.13_all and Meshchat_2.13_all. Both of these Meshchat versions run in your AREDN node, not in your service computer. They are .ipk files, so they will not load into an R-Pi with R-Pi OS (Debian). Maybe that was a source of the reported error messages.
There are two ways to run AREDN. You can put Meshchat-api in your node and run Meshchat_1.02 in your R-Pi, OR put full Meshchat in your node and access the service with a browser. The luci and lua packages (one of each) that are needed to run Meshchats 2.13 and 2.15 with current AREDN firmware are loaded into your node when you load Meshchat. You need do nothing to get them.
When Meshchat is in, you will set up the Service Announcement on your node. It may happen that the Meshchat upload (you can not get Meshchat from AREDN - upload it from computer memory) will provide a prototype announcement so that you only have to edit the Meshchat Zone name. I found that I used port 80 with the api version and port 8080 with the full version, but the api version may be a result of the way we set up the Meshchat config file for Meshchat_1.02 in our R-Pis.
Now the biggest issue. If you want to have Meshchat in your R-Pi, where to get Meshchat_1.02??? Most of the instructions that you find on line reference https://s3.aws-something. That link no longer works. Chuck NC8Q has said he has a directory that has it. I thought I saw his post about it in AREDN Forum, but can no longer find it. I will keep after it, and post here if I find it.
Once you get it, Meshchat_1.02 has a config file that you have to edit in a few places to make Meshchat_1.02 work with the api in your node.
--Tim K5RA
If you want to run Meshchat in your R-Pi, a source for Meshchat_1.02 is found in
https://www.arednmesh.org/content/meshchat-debian-package-where-else-dow...
The two versions of Meshchat 2.15 are available at
https://github.com/kn6plv/meshchat
-Tim K5RA
I'm interested in trying to put 1.02 into a Linux container and see if this will work better. The problem now is that nowhere do I find a complete, up to date list of what to do to get the 1.02 Debian installed and configured, and point the latest package ipk at it. Of course I don't know if this will solve my problem or not.
If anyone has the complete procedure they can share that would be awesome. I know Tim's rather busy lately :-) Ed
I have an RP5B running Meshchat_1.02 with a hAP ac lite running the Meshchat-api_2.15. The Meshchat server has continued to work through many NB installs since early February when 2.13 was released..
From my notes, the only thing we did to the config file was
our $meshchat_path ="/meshchat";
our $pi_zone ='<zone name>';
our $local_meshchat_node ='localnode';
And the service announcement in the hAP ac lite has the zone name, http://<name of rp5b> :80 /meshchat
--Tim K5RA
It turns out that 3.25.2.0 lacks two things needed for MeshChat. "The two dependencies are curl and uci-lib-base" I seem to remember having to upload these dependencies which are ipk packages for an earlier version. In the latest combination of 3.25.2.0 and MC 2.15 there was an assumption that the node had WAN available and would go to the AREDN archives and grab those two packages in the background when installing.
However, just because the computer being used has internet access doesn't mean the node on another network card does. I had wifi access to internet, but the node being flashed no matter if locally on a cable or over the network did not have access to the internet and could not retrieve the two missing packages. I revisited this problem with a hAP that had failed to install earlier, but I was connected to the hAP via LAN either cable or wifi. Connecting to a LAN port or via wifi PLUS cabling the WAN port on the hAP direct to my home router did the trick.
However this is a problem when updating remotely deployed nodes at sites that have no internet access, or for nodes that have only one ethernet port so you can't connect to your laptop and the WAN at the same time.
The solution including for the remote nodes was this. I was connected to the mesh network via a hAP ac lite. The hAP serves me both internet and AREDN traffic. In Network-advanced options there is a slider for
Mesh to WAN
which is normally off for good reason (we don't want internet traffic going over AREDN). I turned that slider option on, then when I uploaded the MC2.15 package remotely to the node it was a success and works fine. I did immediately turn the Mesh to WAN slider back off and saved changes, as that would be awful if I had forgotten.
There apparently is another way to do this, Tim pointed me to AREDN files where the two missing dependencies are stored. He said I can download them and install them one by one like any other package and then MC2.15 will install. However the ipk files are different for each processor type, so it's a bit of work to decode which one you need but this would solve the problem if there is absolutely no internet available where you will be working, so long as you did remember to put them on your local drive before going out to a location with no internet. The other option I've considered is using my cell phone with a USB to ethernet dongle to provide internet access to a WAN port on remote sites ... but that's also something for another day.
I am still working on installing MeshChat into a Linux container on a VM ... but that battle is for another day. At least I can start restoring our local meshchat services.
Thanks Tim,
Ed
Ed K9EOK is doing a Raspberry Pi install of MeshChat,
Tim K5RA is doing an AREDN node install of MeshChat.
AFAIK, the -api.ipk only gets installed on an AREDN node.
If the RPi is serving MeshChat, it gets the meshchat_1.02_all.deb
and the node gets the meshchat-api_2.15_all.ipk.
If the AREDN node is serving MeshChat, it gets
curl, uci-lib-base, meshchat-api_2.15_all.ipk, and meshchat_2.15_all.ipk.
I think.
73, Chuck
Almost.
I have a hAP ac lite with the Meshchat-api. The service computer is an R-Pi 5B with Meshchat_1.02.deb. When the MeshChat-api was uploaded to the hAP ac lite, the luci-lib-base and liblucihttp-lua packages came with it or the install process got them. The packages can be seen in the node packages list.
I have a hAP ac2 with the full Meshchat package. There is no service computer on that node. I use a browser on another node to open windows. When the Meshchat was uploaded to the hAP ac2, the luci-lib-base and liblucihttp-lua packages came with it or the install process got them. After the packages were in, I updated the fields on the Local Service announcement to have the proper Service (MeshChat Zone) Name and to point to the node. There is no Meshchat-api in the node with full Meshchat.
--Tim B K5RA
You specified the meshchat_1.02.deb file for the RPi install, but
ommitted the meshchat*.api that you put on the hap-ac2.
I believe you did not put meshchat_1.02.deb on the hap-ac2.
73, Chuck
You are correct that Meshchat_1.02.deb is not in either of my AREDN nodes. I think trying to install it in an AREDN node will fail.
I just checked my hAP ac2. It shows installed three packages: liblucihttp-lua, luci-lib-base, and meshchat (2.15). The Meshchat-api package is not listed in my hAP ac2. My hAP ac lite has 16 packages (for meshchat and whereandwhen). It has the two luci/lua packages and meshchat-api (2.15).
I can not imagine that the full meshchat would not have the application programming interface (API) built into it.
Apache2 is an open-course HTTP server used for hosting web applications. Curl is an open-source tool for transferring data with URLs. It does various tasks like fetching web pages, interacting with APIs and automating data transfers. Easy to imagine how these apps would be needed by Meshchat in the R-Pi.
--Tim B K5RA
I think:
If I install the package file: meshchat_2.15_all.ipk
I see displayed on the node's installed packages: meshchat (2.15)
This is used when meshchat is running on a node.
If I install the package file: meshchat-api_2.15_all.ipk
I see displayed on the node's installed packages: meshchat-api (2.15)
This is used when meshchat is running on a host on a node's LAN.
The application meshchat_1.02_all.deb is for running meshchat on a Debian host.
73, Chuck
First - I assume that the Tim you mention is Tim W, KN6PLV, the developer of the Meshchat 2.15 packages. He contributes many hours every week to keep AREDN running smoothly in many areas.
Second - Congratulations on finding the kinks for installing Meshchat in your system!
The detailed procedure we use here is for an AREDN node, usually a Mikrotik hAP, and a Raspberry Pi. The first steps are to connect the R-Pi to Internet, to upgrade the RPi to the latest version of R-Pi OS, then install curl and apache2. Next is to download Meshchat_1.02_all.deb and the Meshchat-api_2.15.ipk files to the R-Pi. Then connect the R-Pi to a LAN port on the node and upload the Meshchat. The Meshchat-api 2.15, luci-lib-base and liblucihttp-lua packages are all in the node after Meshchat 2.15 is uploaded.
I have not been able to desk check this procedure with nodes running the New UI. We typically have Internet already available on our hAP nodes either through the WAN port via cable or through one of the WiFi interfaces. Maybe this is why it worked for us in previous installs.
Good luck on the Linux container for a VM.
-- Tim B K5RA
Some questions for you based on your recent post ...
I thought I was supposed to use the smaller Meshchat 2.15 (the one with the longer name) on the AREDN node and point at the computer with 1.02 on it. Hmmm. I do have an almost working version, but when I try to post I get a lock error.
Thanks,
Ed
Ed -
I can not help with X86 with Linux. My X86 is Win 11. I do not know why we install curl and apache2. It is what we have done for years. I believe that R-Pi bookworm already has it. I Googled for answer.
We do not install the Meshchat_1.02 and MeshChat-api_2.15 files in the R-Pi computer at first. They are just acquired from sources and are parked in the RPi. First, the MeshChat_1.02.deb is installed in the R-Pi. Then install the api in the node. When you define the local service on the AREDN node, you point to the computer where MeshChat_1.02 is running.
If you get a new AREDN node, setting up MeshChat is easy with your old computer. Just installed MeshChat-api in the node, and set up the local service announcement as before.
I have looked at my hAP ac lite. It has the API version working with an R-Pi. I also check my hAP ac2. It has the full MeshChat and no attached computer. Both have the three packages to support MeshChat, just the different MeshChat versions. When you access one version, the Chat window shows MeshChat_1.02. The other shows MeshChat_2.15.
--Tim B K5RA
I am also trying to install MC1.02 on a LXC and so far it works but not completely. I understand my hostname, I understand my Zone, I understand well the difference between api and other versions ... etc. My only request now is that could someone share their entire meshchatconfig.pm file that is actually working (for you on your system) so I can compare what you changed to the stock file. It would be best if someone not using a Rpi share, as there are several references in the stock .pm file with the text 'pi' and I am not using a 'pi'
To repeat ... anyone willing to share their entire working meshchatconfig.pm file that is running now on a Linux distro (not on a pi) that would be great.
Thank you,
Ed
According to our procedure, we only change three lines in our config file. Yes, it is AREDN node and R-Pi. I suppose that if your other computer did not have /var, /tmp, /etc, or other folders, it might not work. Is there something in the config file itself that is unique to an R-Pi?
our $meshchat_path ="/meshchat";
our $pi_zone ='<zone name>';
our $local_meshchat_node ='localnode';
And the service announcement in the hAP ac lite has the zone name, http://<name of rp5b> :80 /meshchat
--Tim B K5RA
1 I have the Meshchat 2.15 api package installed on the hAP and it's linked to the 1.02 on the LXC. I also have the full Meshchat 2.15 on the same hAP running in a different zone, and it is functioning correctly. Is this my mistake, trying to have two versions of Meshchat in one AREDN node local services? One points to the node itself, and another points to the LXC, so the local services point to different host names. I was hoping to put multiple LXCs with different host names on one VM. Is this my mistake, hoping I could put multiple Meshchat links onto one AREDN node?
I also am aware that I have not tried to install MC 1.02 on a normal Linux machine, but wanted to clear question 1 up first. I guess I can add another node to the network and move the local service link to that node and see if I answer my own question. I think I'll do that later today.
Ed
PS edit ... well that didn't work. I put another node on port 5 of the hAP, and fired it up. When I went to the LAN DHCP settings to assign a fixed ip address to the host name, it would only show me available ip addresses on the LAN provided by the new node, not the hAP's LAN. Unless there is some advanced trick I haven't yet learned how to make a service available on another LAN than the one I am on ... then that is a bust.
A couple of us were on mesh phones this morning and were talking about your efforts. We were able to see your Local Devices and Local Services. We actually logged-in to one of your MeshChats, and tried to post messages. No go. This sounds like the situation we had last October when AREDN firmware modifications crippled Meshchat. We saw the sort of "one-way transmission" that you appear to see. I will have to look up the details.
KN6PLV is probably best to answer the question if you can have both the full Meshchat and the Meshchat-api with different service announcements, one pointing to the AREDN node and one pointing to the service computer, operating in the same AREDN node. I have never done that.
Can you check the Service Announcements? For those nodes with Meshchat-api and a service computer, we use port 80 in the service announcement. For nodes running full Meshchat, the service announcement uses port 8080. I do not know why, but that is what we do and it works.
A full message directory (default of 500 messages) is about 150KB. That file will fly over the mesh in a twinkling unless there are some really bad links.
You seem so close to getting this going. We are pulling for you. I'll study our old problem this afternoon.
--Tim B K5RA
I got to your nodes through our NTx Supernode, the Oklahoma Supernode, and probably ten other nodes including K1RKS. I found two nodes with your K7EOK call sign with four Meshchat incarnations. Three are on your K7EOK-HAP-ACCESS node and one on your K7EOK-CPE510 node. Here are your node names, the advertised local service names, the Mesh Chat Zone names from the Chat message window, and the version of MeshChat that shows in the Chat message window.
NODE SERVICE NAME ZONE NAME Meshchat Ver
1. HAP-ACCESS MeshChat [chat] Meshchat 1.02
2. HAP-ACCESS MeshChat-MultCo [chat] Meshchat 2.15
3. HAP-ACCESS Meshchat-2329 [chat] Meshchat 2.15
4. CPE510 Meshchat-5735 [chat] Meshchat-5735 2.15
The #1 Meshchat service did not require me to log in. I thought that was unusual. And those services where the service name does not match the zone name on the Chat messages display (#2 and #3) are concerning. I was not able to post a message to Meshchat #1, but was able to post messages to the others. Messages remained even while I went in and out several times. MultCo and -2329 appear to be synching! The zone names are the same in Mesh Chat even though the published service names are different. Do not know how that happens.
I also did some hopping around to look at your neighbor nodes and the MeshChat zone names they use. Some of these nodes are using release 3.24.6.0. I believe it is the case that the MeshChat 2.13/15 needs to be on a node with at least 3.25.2.0. It would probably be good to upgrade to Nightly Build 20250418, since that is now the candidate to be the next release.
It sure looks like your MC2.15 incarnations are trying working. It will be interesting to change MeshChat-5735 to MeshChat [chat] to see if it will synch with the other MC 2.15 nodes.
-Tim B K5RA
All that there should be is MultCo on the node and regular MeshChat in the container. Nothing has changed since I last looked at it a few hours ago. MultCo works and is synced well.
I spoke with a local friend about this this morning. We agreed that we do not know if 1) the package and the api version can function at the same time on the same node. That's why I spun up the CPE to add to the network, and at one point I deleted the package running MultCo. Nothing would get the LXC version going so I put it back but left the detritus. Thanks for noticing.
2) We are also looking at if the issue is running MeshChat in an LXC compared to running in a full VM. We will test that over the next week and see if we get a good sync on another zone name.
3) We also don't know if this will change if we avoid the ProxMox and put it on another server running Linux. So ... lots to work on.
2 and 3 being answered will imply an answer to if there can be more than one MeshChat in the advertised services on one AREDN LAN. If we can do it we will. If not, then we will go back to hosting one instance per node and not worry about it.
The ultimate goal would be to be able to put multiple zone names into separate containers or VMs on the same host ProxMox so we can provide a redundancy for all the the message Zones with one device. This might be impossible, but we have been trying to figure this out.
No rush and thanks,
Ed
The sole remaining hangup as of now is that when using an api / deb version of MeshChat, installed in an LXC, the user logged into the LXC instance sees the various nodes logged into the zone. That user on the container can post messages and they are seen on other nodes. However, the incoming messages from other nodes do arrive in /var/www/meshchat/db/messages.<zone> but never populate out to the GUI for the user to see.
Michael can of course explain this better ...
Ed
It sounds like your work is being rewarded. Maybe not as much or as fast as you want, but something.
I assume you have started and restarted various configurations of Meshchat and the nodes. I think I recall something that could bite you: the old state values do not necessarily get erased when you load a new Meshchat. In the recovery procedure that I developed around the first of the year, at every stage I deleted the service announcement and removed the Meshchat packages, then rebooted the node. That seemed to help. You might consider that.
In the CPE510 that you spun up yesterday, the service announcement name and the zone name were the same. In several of your instances the zone name and the service announcement name are different. That is not what I expect would happen with the full-up meshchat installed in a node. The creation of the service announcement apparently tells the package what zone it is in, so they should be the same.
Please keep us updated as you make more progress.
--TimB K5RA
I seem to remember something like this a while ago when the Oregon mesh had trouble with a corrupted message database. There was some sort of change to the code to fix the issue or we abandoned an old zone name and started up fresh? I can't remember.
I have wondered if there is a list of files left over after telling a node to remove the package that can be deleted manually, so they are re-created from scratch when you re-install the packages? That would be awesome and a good practice to ensure databases stay separated.
Ed
I've been watching you and Michael experimenting with your Zones. Good work! Great to see the MultCo zone name and service advertisement on the same Meshchat service.
Maybe the problem you had a while ago was same we had. There were several messages that had date/time groups in year 2031, and they were ALWAYS at the top of the Meshchat Chat display. We changed our Zone name 2 or 3 times, and eventually cleaned it up. WT0F, I think, generated a config file parameter that is in meshchatconfig.lua that was maybe originally in Meshchat 2.12.0 which is called valid_future_mssage_time = 30 * 24 * 60 * 60. That sounds like 30 days, which to me is much too big. It would filter the giant offenders, but why should times be off by more that a day??
I think what follows is not the answer to your last comment, but it is where I found the files and folders that support Meshchat. I really need to get another hAP ac lite that I can program and unprogram to research what things are clean out and what are left.
If you are using Meshchat-api_2.15 and a service computer running Meshchat_1.02 (LXC, R-Pi, Linux, ...) the supporting files and message logs are in the service computer (R-Pi or whatever you are using). See /usr/bin/cgi-bin for the meshchatconfig.pm and a few other files. See /var/www/html/meshchat for the message (chat) file, a folder of files, and some .js, .css, .html, and an mp3 file. There is also a folder on my R-Pi at root level, /meshchat, which has all the messages that have ever come to the machine. Has over 5200 now listed by a hash code (worthless). Might be able to grep for a pattern to find a specific message.
If you are using Meshchat_2.15, the files are in the node itself. SSH into the node to see them. root@<node name>: ~ /meshchat has a files folder (mine is empty), messages.<zone name> (where the messages are stored), and various supporting files for users, and sync status. :/www/cgi-bin has three files of what appear to be meshchat code, the meshchatconfig.lua file, the meshchat_local.lua file, and several other files apparently for other apps. :/www/meshchat has .js, .css, .html, and one .mp3 support files.
Someday I hope learn how to use grep so I can search for "mesh" in all the file and folder names.
Keep up the good work!
--TimB K5RA