Ah I do love a challenging subject.

The function of "broadcasting" across a mesh won't be doable with just a script.

Typiically in an IPv4 network broadcasting is done by sending to the broadcast address of the network  (10.255.255.255 or 255.255.255.255 for the mesh network.) These packets will not be forwarded past a mesh node as each one is a broadcast break point.  This is also true of the LAN to MESH connection as the nodes are acting as IP routers at this point so you can't just flood the packet from a device on the lan port to a broadcast IP address and have it go out over the mesh interface.

This leaves you with needing to run a program on every node that will participate that will receive your broadcast and regenerate it (OLSR has to do this itself already)

Ultimately you have the following options that I can see.

• Create a daemon and install it on each node
  Any node that is not running the daemon will be a block point
• Use the OLSR daemon to distribute the messages
  -- Create a custom module (olsr sends messages it doesn't understand on without modification meaning no node becomes a block point) and provide a way to submit the messages into the system.

I tend to be weary of broadcasting packets over the entire network if it can be avoided (I've had the discussion of add data to OLSR come up a few times and its a cost/reward discussion in my mind), one should analyze the data they are sending to see how much traffic it will take.  It also should be noted that messages via OLSR are not a guaranteed delivery, they are sent with the expectation they may be lost. This may mean that you need to code a resend system in place for critical items and may need to write your own daemon as noted above (or find one made for Linux already)

Once you figure out what you need you can better evaluate the options for sending messages.

Another less indepth option (if the data in question can work with this) may be to use services to advertise a location, and have a script pick up on the service database to know where to query information from to get its updates. Of course if the information can afford to be lost (similar to a broadcast on a repeater not everyone will always hear it) than an actual broadcast can be much more efficient than constant querying of a central location and can e worth the effort to build in.

This may change whenever we get IPv6 In as MultiCast routing is part of the protocol, but we are not there yet so we can't utilize that solution yet, though MultiCast may provide an option under the install software on each node method in the current version.

Ah I do love a challenging subject.

The function of "broadcasting" across a mesh won't be doable with just a script.

Typiically in an IPv4 network broadcasting is done by sending to the broadcast address of the network  (10.255.255.255 or 255.255.255.255 for the mesh network.) These packets will not be forwarded past a mesh node as each one is a broadcast break point.  This is also true of the LAN to MESH connection as the nodes are acting as IP routers at this point so you can't just flood the packet from a device on the lan port to a broadcast IP address and have it go out over the mesh interface.

This leaves you with needing to run a program on every node that will participate that will receive your broadcast and regenerate it (OLSR has to do this itself already)

Ultimately you have the following options that I can see.

• Create a daemon and install it on each node
  Any node that is not running the daemon will be a block point
• Use the OLSR daemon to distribute the messages
  -- Create a custom module (olsr sends messages it doesn't understand on without modification meaning no node becomes a block point) and provide a way to submit the messages into the system.

I tend to be weary of broadcasting packets over the entire network if it can be avoided (I've had the discussion of add data to OLSR come up a few times and its a cost/reward discussion in my mind), one should analyze the data they are sending to see how much traffic it will take.  It also should be noted that messages via OLSR are not a guaranteed delivery, they are sent with the expectation they may be lost. This may mean that you need to code a resend system in place for critical items and may need to write your own daemon as noted above (or find one made for Linux already)

Once you figure out what you need you can better evaluate the options for sending messages.

Another less indepth option (if the data in question can work with this) may be to use services to advertise a location, and have a script pick up on the service database to know where to query information from to get its updates. Of course if the information can afford to be lost (similar to a broadcast on a repeater not everyone will always hear it) than an actual broadcast can be much more efficient than constant querying of a central location and can e worth the effort to build in.

This may change whenever we get IPv6 In as MultiCast routing is part of the protocol, but we are not there yet so we can't utilize that solution yet, though MultiCast may provide an option under the install software on each node method in the current version.

So, Im working on a project, and I know the OLSR does some checking / beaconing of the local routers connected. What I am trying to do is build a script that will do much the same, only using figures and info input via a PHP form, along with some other device stats. Can anyone give me some insight, or a point in the right direction with this!!

Sound like you are thinking it through and should go well, hope I gave you enough to ponder to understand the final plan and knowing where the limits are. Of course I realize as I put all those questions in I might cause you to make the mistake I often make, waiting for everything, often the solution that exists is better than the solution that is still being built.  Take it in stages with the grand scheme in mind and hopefully you won't have to wait till next December to have something to work with.

Good luck! 

Dahua IPC-HFW4300S

Update: Please do not alter the BBHN firmware for this one particular case. Instead, I will write a Perl (or Python) script to parse the URL passed by BBHN and rewrite the URL in a format compatable with the target camera. And then have Firefox call the script to execute the video streaming client. Not a big deal.

The only downside to doing it that way is that the script would have to be installed on all computers needing access to the video stream from the camera.

Maybe I missed it...what is the make and model of the camera?

AE6XE, thank you for the input. I have been testing the various aspects of the camera and it's interaction with the mesh node URL.

Update: I found a better streaming video client for Firefox. It is called "mpv". The camera insists on getting account / password before it will stream the video. With mpv, I can manually pass all the information in one URL, but the URL is more involved than what a BBHN link will pass to Firefox.

What the BBHN link passes:   rtsp://IPC:554/live

(Where IPC is the configured server in the BBHN node, 554 is the streaming port,  and '/live' is the extra connection info)

What the camera will accept is:   rtsp://[account:password]@IPC:554/live

(An 'mpv' example with a blank password:    mpv rtsp://iwantvideo:@IPC:554/live)

The 'iwantvideo' would be an account configured on the camera in the above example.

If I can get the URL formatted correctly from the BBHN node link, it would be simple to configure Firefox to use 'mpv'

My thanks to everyone who has helped so far.

You may want to be careful with the choice of HTTPS/SSH as both are encryption that obscure the message, it tends to be a hot button topic with many ops and may create some interesting discussions, some times its just easier to avoid having to discuss.

The bigger items I want to bring up are to help you think the scenarios here for the bootup (these are ask your self questions not  questions I'm asking for answers on)

What happens when 2 networks are isolated and than become joined?  Do you run two masters at that point?

Why are you separating the services away from a single node? Is this really an advantage?(note: i want to quantify that 'distributed' design of loosing maybe the file server but not the chat server at the same time DOES count as an advantage) 

What do you consider a 'load'?  We can talk CPU load, we can talk network load etc.

Have you thought about the services trying to move to a more central in the network node based on routing data (a node in the center of the network will give you much better network reliability than a node at the far end of the network)

Everything was working great and someone bumped the power at one of the boxes, the box that has been controlling one of the services (and has all the data)  reboots quickly, but now has an uptime of minutes, what about its data set? Is it being published around or can the network rebuild that data?

Essentially you are talking about Cluster management for an Active/Passive infrastructure with a highly dynamic topology... Very powerful when done right, very code intense to build right. Just wanted to get your brain stirring, the idea sounds good in concept, just wanted to give you ideas on things in the backend to think on.

The basic services you want to offer sound exactly right and provide a method to hopefully make life easier for you, just an implementation item.

So, Im a soldier, and I live in an earthquake/tsunami zone. We have these things called EBOX's, they are a sea containor with some survival equipment and supplies. They are situated around the base to support various numbers of people in various units incase of an emergeny like the ones listed above.

Simply put, their communications system is VERY ineffective. Basicaly there is a CB with a mag mount to toss up on the top of the container. then there is the process of reporting in.... That quickly turns the whole comms setup into a giant crap shoot. Everyone is panicing, wants their turn NOW, and none of them follow any kind of rhyme or reason as to what and how they report that into... Who's listening?? lol So, I am devising a Mesh system to utilize in my community which also has these same EBOXs, but also has ham radio operators associated wtih them.

What I am working on at this point is to have a Raspberry PI act as a host for a local webpage that looks like the images attached to this post. Each EBOX will record its boot time, this boot time will help determine the operation of the services mesh provides. As in, even if EBOX1 boots at 9:00, that doesnt mean its the control host of the (HTTPS & IRC). EBOX8 May have been booted first, at 8:55. Making it the control host. The services being hosted across the mesh are, an IRC, PBX, GeoServer, HTTPS, and hopefuly a method of file sharing.

The reasoning behind determining the boot up sequence, is so that not one node is responcible for all of the load of the services. Services will be booted in a predetermined sequence according to priority. Each node will have to run the HTTP service for their local operation, I will need to decide what to use for reporting.. SSH??.. After that, the next node will run the IRC, then GeoServer, then PBX last. This would requier at least 4 nodes to be fully functional. If I impliment a system to check time and load, the distribution of non-operating services can be started by the nodes with the least amount of load after say a 30 min count down.

This "Load balancing" and "Boot Sequencing" doesnt make any one node the Control Node. A, for lack of better terms, rank structure will dictate what individual is the Controller, and thus wich node is the control node. Just as most nets are operated.

The layout, and basic function of the site I am okay with. How ever, the integration of the rest is going to be the part I need the most work on. Such as, the reporting of individual nodes, and those stats showing up on the other remote nodes in the master tab. i know there is a lot of work to be done, and I will do what I can. I may be asking for assitance or ideas as I go.

For anyone who may not know... the GeoServer application I wish to use, is a kind of standalone, opensource "Google Maps". It has GPS integration, and does not requier an internet connection to operate once it has been setup. The maps are localy stored, and accessable without the need of any outside sources. Which makes it great for this kind of setup.

Any suggestions, or insight are greatly appreciated!

Thank you for reading!

Attachments
 Det Page.PNG [15 KB] ::
 Master Page.PNG [30 KB] ::
 Messaging Page.PNG [28 KB] ::

Memo to Larry:  Attend the local ARC meetings once in a while!!    Apparently locally they are using NW-MESH firmware based on the OpenWRT Attitude Adjustment RC1 release.

A local web site I found is below:  (Stevensville  and Hamilton, MT area)

http://www.meshstuff.com/hsmm-mesh-site/

Since winter has descended upon us here, I doubt whether anyone is interested in updating now.   Good project for the summer, though.  I'll see if I can make contact locally and find out what the plans are.

Larry

Yes. However, I would advise that the some 15 stations be placed in a queue for update.