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

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.