This version is feature complete, just need to find remaining bugs.
Detailed information and installation instructions can be found here:
http://www.trevorsbench.com/meshchat-messaging-for-mesh-networks/
**** Action Script support is now ready for testing. More info here: http://www.trevorsbench.com/mesh-chat-action-scripts/ ****
Installation is the same for v0.7b5 as in the blog post link above. Doc and blog post will be updated when beta is finished. Just change the files for these ones:
AREDN Node: https://s3.amazonaws.com/aredn/meshchat_0.7b5_all.ipk
Raspberry Pi: https://s3.amazonaws.com/aredn/meshchat_0.7b5_all.deb
This is a BETA version. Bugs guaranteed. Please try it and let me know what you find. This will place nicely with v0.6. v0.6 will display all messages regardless of channel from v0.7. You can install this version right over top of any existing version of meshchat.
**** Raspberry Pi / Debian / Linux Users ****
After you install the package you need to edit this file:
/usr/lib/cgi-bin/meshchatconfig.pm
These 2 lines at the bottom:
our $pi_zone = 'MeshChat'; our $local_meshchat_node = 'k7fpv';
$pi_zone is the zone that mesh chat should sync with. Zones are described in the release notes below.
$local_meshchat_node is a AREDN node on your mesh running mesh chat v0.7. The Pi queries this node to get the node list it should poll for the zone it belongs too.
Once those config file changes are made, restart the daemon:
sudo /etc/init.d/meshchatsync stop sudo /etc/init.d/meshchatsync start
So to run mesh chat on a Pi you need to have the same version of mesh chat installed on a AREDN node somewhere on your mesh.
**** If you change your Zone on an AREDN node it is recommenced that your reboot the node for it take effect. ****
v0.7b5 Release Notes:
Use proper port number for file sharing links
Fixed race condition with OLSR and zone discovery, this was causing sync issues
Fix init.d stop to not use killall
Mobile layout fixes
Item counts at top of tables
v0.7b4 Release Notes:
UI queries the message db version and only downloads when it does not match what it has loaded. This dramatically reduces the network traffic and load on the node.
Tighten up white space to bring messages above the fold
Added message search
Change file list sync to use one file per node vs a merged db
v0.7b3 Release Notes:
Action Scripts ready for testing
Ctrl-Enter will send a message vs clicking the Send button
v0.7b2 Release Notes:
v0.7b1 Release Notes:
Zones: You can now have segmented mesh chat databases on a single mesh. Mesh chat looks up the service name it has been given in OLSR. The default is MeshChat. It will only sync with other nodes / pi's that share the same service name. Now you can setup SoCalMeshChat, UtahMeshChat, etc and only the nodes with the same service name will sync with each other. Now when you tunnel into another mesh you won't dump your whole message db into their mesh chat, unless of course you share the same service name.
Change max message db size from bytes to 500 max messages: There was some issues when the db would get full, the whole db would get sent over every sync since the version did not match. To make things simple and robust all message db's are limited to 500 messages so when it is full, the quick version check works properly. Message db's are now stored in sorted order as part of this change too.
Added channels: You select or create a new channel when you send a message. You can select the drop down filter at the top of the message pane to select which messages to display. All message db's contain messages from all channels. They are filtered client side with the display filter.
Action scripts: Action scripts are only supported on the Pi version. This is pretty much done but needs more testing. If you feel adventurous you can add a line in /etc/meshchat_actions.conf You can read the comments in that file on what kind of matches you can do. I have a SMS gateway and archive working. More details and code to come.
v0.7b5 works on a RPI rinning HSMM-pi with xastir!
the problem I fund is that the hsmm-pi distro, the service announcement is not getting out ( the problem is being worked)
SO I can only define ports ie http://KJ6DZB-4.local.mesh:8080
I cant announce http://KJ6DZB-4.local.mesh:8080/meshchat
working the prolem... Surprise im the first one to notice this...!
hsmm-pin haven't kept up on the protocols involved and last time I saw them work on well documented code they just threw random code at it appearing to have no understanding of what they were doing so I'm not surprised this is an issue. This includes lack of DTDLink support meaning the nodes are jamming the RF (as discussed elsewhere) since I've never heard of one get reasonable distance nor a reasonable method to deploy them in the field. I have even heard of HSMM-PI's being so poorly configured they crashed some networks in New Zeland (apparently throwing completely garbage data of some sort, never got packet logs to see this but concerning all the same) Should a support issue arise one can expect that it would be rejected if it can't be duplicated without the hsmm-pi in the mix.
on my FreePBX Pi.
Seems like b5 broke something (since b4 was working fine).
The install of the deb version removed my advertised service link but that was eay to put back.
The problem is that I am no longer able to post messages as in early versions except this time I do not see messages from *other* nodes either.
I do see the other stations in the sync status page and mesh chat users table.
I am running the same (b5) version on my Ubiquiti node (which works fine)
Is there something in mesh chat that's depent on the http://KJ6DZB-4.local.mesh:8080/meshchat announcement?
Ive modified the 2 lines, changing the local mesh chat node to another node with 5b. Nothing! Has any one done a fresh install with a RPi for B5 ?
The hsmm-pi project uses a standard config from official olsrd git. 0.6.8 there is not much to mess up. There was a problem awhile back when BBH was using outdated olsrd code, while Hsmm-pi wasn't. The Hsmm-pi project is not going to replace a Ubiquity's hardware LOL! It gives a platform access to an OLSRD wireless Mesh. In my case I can run an APRS digireptor with minimal power consumption costs, and have it connected to the mesh. I only became interested in running mesh chat on the node when I came up with the idea of sending aprs messages. How Ive got to run mesh chat on the node as well! IT adds one more thing to go wrong in my mind. I support the idea of another instance of Mesh chat to handle scripting for SMS or APRS. If this install is going to confilict with whats running, Im going to get to the bottom of it.
Yeah - b5 is broken for the PI. Mine did not work either (as I posted).
Tonight I installed b4 again - right on top of b5 - and got things working again.
b4 on the PI seems to work fine with its required Ubiquiti mate running b5
the down grade didn't do the trick ;-(
Dose any one what to dissect my install before I start fresh? again.
73 I break things until they work...
(Using Raspbx build)
https://s3.amazonaws.com/aredn/meshchat_0.7b6_all.deb
I have updated both the FreePBX application and Mesh Chat on my raspberry pi and now it is bogging down. Indicated loading is around 2.5-3 on the version of top that comes with the FreePBX install. Keyboard response on the GUI can be pretty slow depending on what you ask for and when you ask it.
Is there some way (or what is the proper way) to "turn off" Mesh Chat, so I can evaluate the incremental CPU loading caused by it?
OK: answering my own question-
in summary - mesh chat does not cause much load at all on the PI. But it does write a file every 2.5 seconds. My Pi got into some strange mode where writing to mmcblk0p2 was causing the CPU to go into a wait condition (as seen on 'top'). Asterisk/PBX writes from time to time too, so stopping Mesh Chat did not have a big effect. The system had slowed to a crawl. Rebooting did not help - it took a full power-off cycle to get things back to normal. Now its running with a load of less than 0.2 and no waiting.
I have done a complete R-PI update/upgrade and FreePBX update and will just watch and wait.
Can that file that's being written so often be put in the RAM disk? Would it hurt if it was lost at a reboot? That should be a lot faster and reduce the write-cycle wear on the SD memory.
Bill
overnight the system went into slow motion mode again. I did two things:
1) stopped Mesh Chat and ran FreePBX all day: no problem
2) Stopped FreePBX and ran Mesh Chat all night: no problem
Started FreePBX so that both programs were running at the same time. In less than an hour the system started to slow down.
Reported system load went from 0.4 to as high as 2.4 with 2 or 3 CPU's reporting high percentage wait states.
The process that is encountering wait states is mostly the one that writes files
This wait state problem only occurs when both asterisk (FreePBX) and Mesh Chat are running at the same time. Both programs write files. So perhaps there is some conflict/contention between the two of them for file access.
Note - the list above is generated by this little script:
San Disk Ultra, Class 10, 32 GB.
=========================
I found something interesting.
Looking at the content, the files in /proc/56/cwd/tmp/meshchat/ are actually mesh chat files. But asterisk "owns" some of them. Perhaps this is another manifestation of the permissions problem. (Its the top two files that get written every few seconds).
I was surprised that you actually change the ownership of these files even though it is in the /proc/ directory.
I think maybe if the mesh chat program was installed, and ran, under a separate user name, perhaps this ownership battle would go away. Seems like that would be good practice anyway. That;s my suggestion and I would be happy to test it.
Our Mesh Chat has gotten a lot of use by multiple users the past couple of weeks and today maybe even more so. However when I was done with all the technical stuff and needed a break, I tried to send some longer sign-off text that apparently fouled things up for everyone and now mesh chat seems to be clear of all past entries and new text entered does not show up. I (we?) can't get anything going on it at all I tried uninstalling and reinstalling mine (AirGrid) but nothing changed. I think this is what I tried to past and send:
____
< 73 >
----
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
It could have been something similar before that actually did it. I'm not sure. I guess sooner or later someone else would have tried something like that, maybe. Please help.
- Mike
Looks like a perfectly good Perl script program to me!
Just to be clear, it looks like there are 6 nodes being synced with Mesh Chat according to the status screen. But I believe everyone is dead now and cannot use Mesh Chat. All history is lost too. I can log in and out but otherwise, no text entries seen. I believe there is at least one tunnel. - Mike
ssh or telnet to EACH node that has Meshchat installed in your zone
run: /etc/init.d/meshchatsync stop
EVERYONE NODE WITH MESHCHAT MUST DO THIS BEFORE PROCEEDING TO THE NEXT STEP
run: rm /var/meshchat/messages.MeshChat (or whatever your zone is named) (ie. "messages.MeshChat" or "messages.My.Custom.Zone")
EVERYONE NODE WITH MESHCHAT MUST DO THIS BEFORE PROCEEDING TO THE NEXT STEP
run: /etc/init.d/meshchatsync start
Hope this helps.
Darryl
Thanks Darryl. I followed your procedure and it looks like it worked fine.
73 - Mike
Ron
Can we do that with mesh chat?
Bob W8ERD
MeshChat can accept files and make them available for download, but, it's not intended to be a "private" or point-to-point messaging system.
Suggestions? Bug? Feature?
I had messages from the global zone in my custom zone messages file after that.
wierd.
I ended up stopping the meshchatsync, deleting the messages file, and restarted sync in order to clear it.
Thanks
There is no "receiving node" in MeshChat. In general terms you can think of MeshChat like the old time bulletin boards, where you connected to a location where it was running and posted a text note for all interested parties to read. Those interested parties had to check that BB to see the most recent posts to find them., It was/is a "pull" type design, there is no "push" to direct or deliver msgs.
MeshChat only needs to run on a node which you can reach from yours. It resides and runs there. If a MeshChat node finds another instance of the same name MeshChat running on the same mesh, it shares its database by copying the most recent updates with all other instances. The effect of this is that the database of msgs then automatically becomes somewhat resilient and stays alive until the last copy of MeshChat is turned off. IOTW, it regenerates thru the mesh as long as one instance is "alive".
You can have MeshChat installed on your node if you wish, and that makes if faster for you to use, and also helps keep alive the "mesh" of that msg database - but you DO NOT NEED to install it on your node to use it on another node as long as you can follow that other node's link from your Mesh Status page. It is all one big shared msg database shared by all instances with the same name MeshChat.
Hope this makes sense, it works well here on our multi-mode "Mesh Island" where only some of our "critical" nodes have it installed. Eventually we'll also install it on a PI but it's not necessary.
A few things to note: you CANNOT edit a msg once posted; even though you can use "folders/categories" to sort by topic or whatever, all msgs are readable by all who have access, and all may post to it; finally, there appears to be no enforcement on the "CallSign" login, one can use anything you like (your call, you name, another call, a tactical name, your dog's name, whatever).
HTH,
- Don - AA7AU
Your info was a big help. Thanks