You are here

meshchat v0.7b5 released

42 posts / 0 new
Last post
K7FPV
meshchat v0.7b5 released

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:

Play sound alert when a new message arrives
Mobile layout fixes
Permission problems on FreePBX - thx KE2N
Action Scripts ready for testing
Ctrl-Enter will send a message vs clicking the Send button

v0.7b2 Release Notes:
Fixed Updated secs on files and status pages
Poll lists / zone fixes
Lowercase node names on Pi
File table layout fix
Detect apache user and set permissions accordingly
Fixed height on channel drop down
Keep log of message ids processed by action scripts so they can’t repeat
Support USB drive for files on AREDN node if mounted
Action script log on status page 

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.
Fixed + in messages
Added version, node, call sign, and zone to top of every page
Cleaned up interface
Added config option on Pi for mesh chat node - see above
Added config option for zone name on Pi - see above
k1ky
k1ky's picture
MeshChat 0.7b5 Item Count on Tables

Looks like the new "ITEM COUNT" feature is working in the STATUS area just fine - thanks! Should there be an item count in the MESHCHAT USERS box too (I don't see it) if not - please consider for next release.

K7FPV
Maybe try refreshing or

Maybe try refreshing or flushing your browser cache there is a count on users too.

k1ky
k1ky's picture
Yes, I see it on "some"

Rebooted the unit - I do see a user count on my unit in a different Zone.  Tried different browser - no joy there either.  Will do some more testing.  I'm getting a different station count on 2 units - It has something to do with the use of Zones.

k1ky
k1ky's picture
Yes, a Screen Refresh does it

That did the trick! Shift reload browser tab.   Wonder if this explains some other anomalies I was getting when trying to use Zones.  So far so good on the Zone issue.  It is counting the users properly per zone.

kj6dzb
kj6dzb's picture
well 

well 

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...!

K5DLQ
K5DLQ's picture
you absolutely don't need

you absolutely don't need hsmm-pi for this.  A regular pi connect to the lan of another node works great.

KG6JEI
Nor would I recommend using

Nor would I recommend using an hsmm-pi for it.

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.

K7DXS
Reasonable method to deploy

Reasonable method to deploy them: SMA Wi-Fi adapter plus SMA 2.4GHz antenna plus literally any solar panel phone charger.

As for the support issue thing, that is exactly how issues work, right? If it's an issue with someone else's project, it's not your responsibility.

KE2N
KE2N's picture
7b5 debian

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)
 

kj6dzb
kj6dzb's picture
The b5 install is not working

The b5 install is not working on the my pi. Whats not working ? Is it the Beta5 ? Im dont know... 

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!  

What exactly is the difference between the rpi version and the node version?

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.







 

KE2N
KE2N's picture
b5 broken

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

 

kj6dzb
kj6dzb's picture
Thanks KE2N 

Thanks KE2N 

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...

K5DLQ
K5DLQ's picture
I can also confirm that b5 is

I can also confirm that b5 is not working on my Pi.  Interestingly, it creates a file without the leading "messages" in the db dir like:   .MeshChat.MONT.TX.US.NOAM  instead of messages.MeshChat.MONT.TX.US.NOAM.  Also, this file is owned by root instead of asterisk.

(Using Raspbx build)

KG6H
Fresh Pi install works

I never had MeshChat on my Pi before, so it was a fresh B5 install. I pointed it at a local RocketM5 I have and it replicates fine. Would be nice if the Pi could operate without a Mesh AP running MeshChat, but I guess that is due to routing needs?

K7FPV
Sorry on vacation I'll look

Sorry on vacation I'll look at the bugs next week

K7FPV
For anyone having problems

For anyone having problems with b5 on a pi / debian box please try this b6 for me. This will overwrite your meschchatconfig.pm so you will need to edit it and restart the daemon. The problem look to be something with the packaging and conf files.

https://s3.amazonaws.com/aredn/meshchat_0.7b6_all.deb

KE2N
KE2N's picture
on off switch?

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-

sudo /etc/init.d/meshchatsync stop


 

KE2N
KE2N's picture
RPI

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.
 

wa7nwp
RPI and Meshchat


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
 

KE2N
KE2N's picture
more investigation

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

D    56 [jbd2/mmcblk0p2-]
D 29977 [kworker/u8:2]
----
D    56 [jbd2/mmcblk0p2-]
----
D    56 [jbd2/mmcblk0p2-]
----
D    56 [jbd2/mmcblk0p2-]
D 29977 [kworker/u8:2]
----
D    56 [jbd2/mmcblk0p2-]
D 29977 [kworker/u8:2]
D 31444 [kworker/u8:0]
----
D    56 [jbd2/mmcblk0p2-]
----
----
D    56 [jbd2/mmcblk0p2-]
D 29977 [kworker/u8:2]
----
D    56 [jbd2/mmcblk0p2-]
D 29977 [kworker/u8:2]
----
D    56 [jbd2/mmcblk0p2-]
----
D 29977 [kworker/u8:2]
----
D    56 [jbd2/mmcblk0p2-]
D  1548 /usr/bin/perl /usr/lib/cgi-bin/meshchat
D 29977 [kworker/u8:2]
----
D    56 [jbd2/mmcblk0p2-]
D  1548 /usr/bin/perl /usr/lib/cgi-bin/meshchat
D 29977 [kworker/u8:2]
----
D    56 [jbd2/mmcblk0p2-]
D 29977 [kworker/u8:2]
----
D    56 [jbd2/mmcblk0p2-]
D 29977 [kworker/u8:2]
----
----
D    56 [jbd2/mmcblk0p2-]
D 29977 [kworker/u8:2]
----
D    56 [jbd2/mmcblk0p2-]
D  5678 /usr/bin/perl /usr/local/bin/meshchatsync
D 29977 [kworker/u8:2]

 

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:

for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done




 

K5DLQ
K5DLQ's picture
Are you using a Class10 SD

Are you using a Class10 SD card?

KE2N
KE2N's picture
yup

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).
 

Image Attachments: 
KE2N
KE2N's picture
mesh chat co-existing

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.

AB4YY
Mech Chat broken (v0.7b5)

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
 

KE2N
KE2N's picture
Hieroglyphics

Looks like a perfectly good Perl script program to me!

AB4YY
Mech Chat broken (v0.7b5)

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

K5DLQ
K5DLQ's picture
From my research, here's what

From my research, here's what you can do to wipe out your messages (and get rid of the offending text)...

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

AB4YY
That fixed it!

Thanks Darryl.  I followed your procedure and it looks like it worked fine.
73 - Mike

K5DLQ
K5DLQ's picture
awesome!  

awesome!
 

KG6HSQ
Feature request, expire date

Would be nice to be able to remove/ignore messages before a certain date, on a node. Good for house keeping and get rid messages that live forever.

Ron

w8erd
Private Files

Our ema director would like us to send press releases via the mesh.  Presumably these are intended to be private between 2 stations.
Can we do that with mesh chat?  

Bob W8ERD
 

K5DLQ
K5DLQ's picture
I would recommend RMS Express

I would recommend RMS Express in Telnet P2P mode.  It's perfect for this.

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.

k1ky
k1ky's picture
MeshChat Zone Traffic Crossover 0.7b5

I'm still experiencing some "One Way" Message crossover from a separate Zone into the main MeshChat database.  I have tried different zone names and the results seem to remain the same.  If I enter a message on the TNMeshChat Zone, that message goes both to the TMeshChat Zone as well as the regular MeshChat Zone.  Traffic from MeshChat zone is not seen by the TNMeshChat Zone.  Same thing with our AKMeshChan and CamperMeshChat zones and others.

Suggestions?  Bug?  Feature?


 

K5DLQ
K5DLQ's picture
i saw this once here.  I

i saw this once here.  I think I had my Pi instance pointing to a local node that didn't have meshchat originally.  I installed it which then gave an advertisement for MeshChat.  I think later changed it to a custom named zone.
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.
 

k1ky
k1ky's picture
Nope - that didn't get it

I stopped all of the Meshchatsync operations on each node in the Zone, cleared all of the databases (removed them) and then re-enabled the Meshchatsync operations on each node.  Still get message crossover from the Special Zone back into the regular MeshChat Zone database.

K5DLQ
K5DLQ's picture
do you have a Pi pointing to

do you have a Pi pointing to a node (in the localnode config setting) that has a "MeshChat" service defined?

k1ky
k1ky's picture
No PI's here

I don't have any - but I'm sure that there are some others out there that aren't mine that are connected to our system via tunnel.  Do we need to do something with them?

N5MXI
N5MXI's picture
Newbie meshchat question

Does the receiving node have to meshchat loaded in order to work or just the sending node? Still trying to learn how this all works.
Thanks

K5DLQ
K5DLQ's picture
It's recommended that

It's recommended that MeshChat API be installed on a node (very lightweight), and the full MeshChat package installed on a RaspberryPi.

AA7AU
AA7AU's picture
There is no "receiving node"

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

N5MXI
N5MXI's picture
Thanks Don

Your info was a big help. Thanks

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer