Skip to main content

FAQ: 3. Server Administration

3.1. Q: How do you configure a repeater or a room server?

A: - When MeshCore is flashed onto a LoRa device is for the first time, it is necessary to set the server device's frequency to make it utilize the frequency that is legal in your country or region.

Repeater or room server can be administered with one of the options below:

  • After a repeater or room server firmware is flashed on to a LoRa device, go to and use the web user interface to connect to the LoRa device via USB serial. From there you can set the name of the server, its frequency and other related settings, location, passwords etc.

!image

  • Connect the server device using a USB cable to a computer running Chrome on https://flasher.meshcore.io, then use the console feature to connect to the device
  • Use a MeshCore smartphone clients to remotely administer servers via LoRa.
  • A T-Deck running unlocked/registered MeshCore firmware. Remote server administration is enabled through registering your T-Deck with Ripple Radios. It is one of the ways to support MeshCore development. You can register your T-Deck at:

3.2. Q: Do I need to set the location for a repeater?

A: While not required, with location set for a repeater it will show up on the MeshCore map in the future. Set location with the following command:

set lat

set lon

You can get the latitude and longitude from Google Maps by right-clicking the location you are at on the map.

3.3. Q: What is the password to administer a repeater or a room server?

A: The default admin password to a repeater and room server is password. Use the following command to change the admin password:

password {new-password}

3.4. Q: What is the password to join a room server?

A: The default guest password to a room server is hello. Use the following command to change the guest password:

set guest.password {guest-password}

3.5. Q: Can I retrieve a repeater's private key or set a repeater's private key?

A: You can issue these commands to get or set a repeater's private key using a USB serial connection.

get prv.key to print a repeater's private key on the serial console

set prv.key to set a repeater's private key on the serial console

Reboot the repeater after set prv.key command for the new private key to take effect.

3.6. Q: The first byte of my repeater's public key collides with an exisitng repeater on the mesh. How do I get a new private key with a matching public key that has its first byte of my choosing?

A: You can generate a new private key and specific the first byte of its public key here: https://gessaman.com/mc-keygen/

Having multiple repeaters with the same first byte ID does not negatively affect the mesh or its functionality. Flood and pathed packets will still reach their destinations. First byte ID collision makes traceroute and path analysis harder because these tools don't know exactly which of the two (or more) colliding repeaters is the one in the path.

Best practice is when you set up a new repeater, choose a public key that is not in use. If it is not possible to find a unique first byte for your repeater's public key, choose one that is unique within about 10 miles (16 km) to minimize collision with nearby repeaters.

3.7. Q: My repeater maybe suffering from deafness due to high power interference near my mesh's frequency, it is not hearing other in-range MeshCore radios. What can I do?

A: This may be due to the SX1262 radio's auto gain control feature. You can use this command to periodically reset its AGC.

set agc.reset.interval

The unit is in seconds and is incremented by 4. set agc.reset.interval 4 works well to cure deafness.

This is a very low cost operation. AGC reset is done by simply setting state = STATE_IDLE; in function RadioLibWrapper::resetAGC() in RadioLibWrappers.cpp

3.8. Q: How do I make my repeater an observer on the mesh?

A: The observer instruction is available here: https://analyzer.letsmesh.net/observer/onboard

3.9. Q: What is multi-byte support? What do 1-byte, 2-byte, 3-byte adverts and messages mean?

A:

The original MeshCore protocol design uses the first byte of a repeater's public key to denote the repeater in a path. And with 1 byte for each repeater in the path, MeshCore packets can travel as many as 64 hops.

However, with 1 byte, there are only 254 unique IDs (exclude 00 and FF which are reserved). Many meshes group have multiple repeaters with the same first byte in their public keys. Packets continue to pass through repeaters and the mesh is not harmed in anyway. It does make it harder for tools to analyze paths with duplicated repeater IDs.

Firmware version 1.14 and newer introduces the ability for repeaters to advert with 1-, 2-, or 3-byte adverts. Companions can also send out channel and direct messages with 1-, 2-, or 3-byte path. Adverts and messages sent in 1-byte path is compatible with repeater firmware older or newer than 1.14. They will travel up to 64 hops. 2-byte adverts and messages will travel up to 32 hops. 3-byte adverts and messages will travel up to 21 hops.

3.9.1. Q: What path hash sizes will my repeater forward?

Repeaters running firmware 1.14+ repeat packets sent with 1-, 2-, or 3-byte path hash. Repeaters on firmware older than 1.14 only repeat 1-byte path hash packets and silently drop 2- and 3-byte packets.

3.9.2. Q: What determines a packet's path hash size?

The original packet sender determines the path hash size. The most common original sender is a companion app. The other common original sender is a repeater, when it broadcasts its advert.

3.9.3. Q: How do I change my companion's path hash size?

As of firmware version 1.14 and MeshCore app version 1.41.0, in the MeshCore app, you can set your companion's message path hash size in Settings (gear icon), Experimental Settings.

Until your regional mesh has the vast majority of the repeaters updated to 1.14+ firmware, it is recommended to keep your companion at the default 1-byte because pre-1.14 repeaters will silently drop messages with larger path hashes.

3.9.4. Q: What does the CLI command path.hash.mode do on a repeater?

This CLI command path.hash.mode only controls the path hash size used in a repeater's own advert broadcasts. It does NOT affect which packets the repeater forwards. A repeater with firmware 1.14+ always forward 1-, 2-, and 3-byte packets regardless of this setting.

Usage: set path.hash.mode {0|1|2}:

┌────────────────┬───────────────────────┐
│ path.hash.mode │ Advert path hash size │
├────────────────┼───────────────────────┤
│ 0 │ 1 byte (default) │
├────────────────┼───────────────────────┤
│ 1 │ 2 bytes │
├────────────────┼───────────────────────┤
│ 2 │ 3 bytes │
└────────────────┴───────────────────────┘

It is safe to set your 1.14+ repeaters to mode 1 or 2.

3.9.5. Q: Why use 2- or 3-byte path hash for adverts?

A longer path hash helps tools like the LetsMesh.net Analyzer and MeshMapper disambiguate repeaters more reliably. With only 1 byte, the chance of different repeaters having the same first byte in their public key is high, making it harder to tell them apart in mesh network analysis. Since this only affects adverts, there's no downside. 2- and 3-byte adverts don't travel as far as 1-byte adverts, but it is not important for MeshCore nodes to hear a repeater's advert that are 21 or 32 hops away.

3.9.6. Q: When can we move away from 1-byte path hash for channel and direct messages?

You should move to send 2-byte or 3-byte channel and direct messages when the vast majority of the repeaters in your regional mesh are updated to firmware version 1.14 or newer. Setting your repeater's path.hash.mode to 1 (for 2-byte path hash) or 2 (for 3-byte path hash) now helps the community gauge to how many repeaters have updated to 1.14+. Please work with your MeshCore community together to decide when to switch to 2-byte path or 3-byte path for channel and direct messages.

---

No comments to display

Back to top