Looking for some gentle nudges in the right direction...

I'm tinkering with on-mesh, mesh-only email.  I envision a regional or nationwide mesh that will one day have email capability.  Towards this end I built two raspberry pi email servers using information from http://www.samhobbs.co.uk/raspberry-pi-email-server.  I used only the first two tutorials and did not include the SSL/TLS capabilities.  Both Raspberry pi have names (nwf.local.mesh and fwb.local.mesh), they are attached to separate mesh nodes and I can connect to either one of them using the IP or the name without issue.  I can set up a mail client that can receive mail and I can connect to both smtp servers on the mesh to send email.  The problem I'm having is when one mail server attempts to connect to the other. 

My Mesh Configuration:

(RF)-[N2XU-First]-cat5-[RasPi: fwb.mesh.local]

(RF)-[N2XU-Second]-cat5-[RasPi: nwf.local.mesh]

If I attempt to log onto fwb as pi@fwb.local.mesh and send mail from pi@fwb.local.mesh to pi@nwf.local.mesh on the other server the log says it can't find a MX for nwf.local.mesh. The email does show in the sent folder but never arrives in the pi@nwf.local.mesh inbox on the other server.  Apparently it's doing a DNS lookup for the MX record of the other server.  Is there a way to include MX records in the DNS records on the mesh nodes that will propagate across the mesh.  I just encountered this a little while ago and did a search here on the forum for MX and didn't get any results.

I don't believe that everyone will run an email server, but I do believe that there could and should be at least one somewhat local in each area... maybe by county, or region of a state.  Has anyone else experimented with mesh only email with more than one email server?

Thanks.

Tom

Real bad here... I turned DHCP off.. Don't ask my why I turned that off.. How do I get back to my nodes?  I have both the Linksys and bullet devices.. I have like 8 nodes..

THanks

Anyone using the Linksys WSB24 "wireless signal booster" 2.4 GHz amplifier?

I have one here and am wondering if anyone has any experience with it?

Vy 73, AI2Q, Alex

Anyone using the Linksys WSB24 "wireless signal booster" 2.4 GHz amplifier?

I have one here and am wondering if anyone has any experience with it?

Vy 73, AI2Q, Alex

well there you go!  Is there any futures for this device being supported?  BTW, awesome news on the 5 Ghz support!!

The firmware only supports M-series UBNT devices. Andre, K6AH

Hi, I am new to HSMM but hoping to get better at it.

I have a Linksys WET54G that is quite happily picking up the WIFI in my home. If I connect it via an Ethernet cable to my laptop running Ubuntu Linux, disable WIFI on the laptop but enable cable connection, I can still browse the internet. So I know the Linksys WET54G is working. However, when I connect the WET54G to my WRT54G running HSMM-Mesh on the internet input, the system time doesn't update. Therefore, I am sure that the WRT54G is getting a time signal but the set-up is wrong. Has anyone got any ideas on how I can get the WRT54G hear the WET54G please?

Many thanks, Robert M0NVQ

Hi, I am new to HSMM but hoping to get better at it.

I have a Linksys WET54G that is quite happily picking up the WIFI in my home. If I connect it via an Ethernet cable to my laptop running Ubuntu Linux, disable WIFI on the laptop but enable cable connection, I can still browse the internet. So I know the Linksys WET54G is working. However, when I connect the WET54G to my WRT54G running HSMM-Mesh on the internet input, the system time doesn't update. Therefore, I am sure that the WRT54G is getting a time signal but the set-up is wrong. Has anyone got any ideas on how I can get the WRT54G hear the WET54G please?

Many thanks, Robert M0NVQ

I have tried to flash my pico2 HP devices (I got 4 for a steal..) via AirOS; says bad image file.  I tried to tftp via this process below, and says bad file..  <this is the file I am trying to use bbhn-1.1.2-ar71xx-generic-ubnt-bullet-m-squashfs-factory.bin>

1. Set your PC to be able to access the bricked unit and prepare the firmware file:
2. Prepare your TFTP client to push the firmware.bin file so you can start it with just a hit of a button. Do not start the push yet.
   • Using the Windows integrated TFTP client the command to prepare is: "tftp -i 192.168.1.20 PUT [path to file]\firmware.bin"
3. Unplug the bricked unit.
4. Plug the LAN connection of the PoE injector directly to your PC's NIC.
5. Keep the unit's reset button depressed and plug in network/PoE in the unit.
   • Keep the reset button depressed until you see the light cycling relatively fast through amber/green/off colours (~14 seconds from power on) -> Release it. Now the device is in TFTP transfer mode.
6. Engage the TFTP push command and wait. The device will write the firmware and it will reboot.
   • If you wait too long to start the tftp, the push will not work as the device will stall. Please redo from step 3.

Version 1.1.2 has been released to resolve the issue described by Peter and is available from the downloads page and the Administration page of the node.

In theory this should work if you are able to connect to the remote node using the "meshnode" ssid for the setup phase.  If you do not have a direct link then this is not going to work.

I would practice at home before I attempted this.  Worst case is you will have to get close enough to the node to make the  "meshnode" connection.

In my case I have a set of remote nodes that have to go through another set of nodes to get to my QTH.  I can't use this method unless I drive close enough to the distant set of nodes to be able to get the "meshnode" connection.

Also note that if you have multiple nodes at the remote location, you probably want to go to the site anyway to link them together with Ethernet cords.  If you have just two nodes you can tie the lan ports on the poe together.  If you have more than two connect the lan port to a switch (it doesn't have to be a managed switch) or if there is a WRT54 as the site just use the lan ports on it.

The back to back connections dramatically improve the throughput of the node compared to connecting using the wifi.

Clint Anderson, AE5CA

I have tested a way to do remote upgrades of nodes that has worked for me "in the lab".  Here's the scenario I tested:

1) Rocket M2 (device #1) with 1.0.1 firmware and access over mesh to device #3 below.   This is the Target remote node to upgrade.

2) Bullet M2 (device #2) with UBNT factory firmware and configured in wireless settings:

2a) Wireless Mode = "Station"

2b) SSID = "MeshNode"

3) Bullet M2 (device #3) running 1.0.1 firmware with internet gateway and/or attached computer with the 1.1.1 firmware file previously downloaded.

4) Local computer with network cable plugged into device #2 in DHCP mode.  Turn off wireless. (re-purpose computer in #3 at the appropriate step.)

Steps to do remote upgrade (Line of sight sufficient for device #1 and #2 to communicate with each other given conditions and antennas):

1)  Using the computer attached to device #3, remotely access setup of Device #1 and upload and/or download the 1.1.1 firmware version to perform the upgrade.  Device #1 *should* go through full process and reboot with new firmware.  Do "wscan" from Device #3's computer to confirm an SSID of "MeshNode" is showing and the step completed successfully.  

2) Power on Device #2 (re-image device #3 with ubnt factory and configure) and align antenna with Device #1 antenna (still pointing to remote node which is now in AP mode waiting to be configured for the first time).

3) Power on computer and via Device #2 (acting like a layer 2 wifi to lan bridge), your laptop will receive a 192.168.1.x address (from device #1).  

4) browse to "localnode:8080" and perform the setup with callsign, etc. and remotely reboot.

5) Now upgrade local Device #2 to 1.1.1 firmware.

Note, in step 1, I said the node "should" reboot.  When I did this for real on my 5-mile away node, it didn't complete :(, where as in the lab, it did :) .  So no guarantees.

Happy meshing!  73's AE6XE

Just an additional note / reminder,  if you change the secure key make sure to change the network SSID as well.

Users expect that if they see a BroadBand-Hamnet SSID they will be able to connect to it without changing a key or any other configuration.

Keeping the protocol identifier is also recommended (Aka MyNet-v2) to help you manage your network long term and remind users what the hardware is running and segment your upgrades in some cases.

Your question came in on a release week, this means most the people whom might have the skill to answer this question are generally fairly busy.

All mesh technologies have the same need,  they need to publish the details of nodes in a network so that way a routing decision can be made.

Scaling depends on a LOT Of factors, everything from number of nodes, to distance between nodes, link quality between nodes, settings used for propagating the information.

It is impossible to give a exact scaling factor for any network.

Most routing projects share one of a few common daemons, OLSRD and Batman are the two most common to my knowledge  with OLSRD  being a defined standard.

QMP is actually just a frontend of some solution I have never heard of,  and the CJDNS you linked talks about being an encrypted protocol which may not work for Amateur Radio.

Like most items in networking one has to evaluate the deployment and watch how it is performing and evaluate changes in response to the needs of an environment.

Unable to duplicate in my lab in 1.1.1

Installing ngircd needs openssl and zlib as dependencies.

With internet to the node selecting ngircd and starting it from the command line works without issue on my Bullet M2.