new error codes

docs/docs.md

@@ -232,8 +232,8 @@ remote gpio are managed as an example
 | bandwidth | [uint32](#uint32) |  | Bandwidth in MHz Certain bandwidth numbers are 'special' and will be converted to the appropriate floating point value: 31 -> 31.25MHz |
 | spread_factor | [uint32](#uint32) |  | A number from 7 to 12. Indicates number of chirps per symbol as 1<<spread_factor. |
 | coding_rate | [uint32](#uint32) |  | The denominator of the coding rate. ie for 4/8, the value is 8. 5/8 the value is 5. |
-| channel_num | [uint32](#uint32) |  | A channel number between 1 and 13 (or whatever the max is in the current region). If ZERO then the rule is "use the old channel name hash based algorithm to derive the channel number") If using the hash algorithm the channel number will be: hash(channel_name) % NUM_CHANNELS (Where num channels depends on the regulatory region). NUM_CHANNELS_US is 13, for other values see MeshRadio.h in the device code. hash a string into an integer - djb2 by Dan Bernstein. - http://www.cse.yorku.ca/~oz/hash.html unsigned long hash(char *str) { unsigned long hash = 5381; int c; while ((c = *str++) != 0) hash = ((hash << 5) + hash) + (unsigned char) c; return hash; } |
-| psk | [bytes](#bytes) |  | A simple pre-shared key for now for crypto. Must be either 0 bytes (no crypto), 16 bytes (AES128), or 32 bytes (AES256) A special shorthand is used for 1 byte long psks. These psks should be treated as only minimally secure, because they are listed in this source code. Those bytes are mapped using the following scheme: `0` = No crypto `1` = The special default channel key: {0xd4, 0xf1, 0xbb, 0x3a, 0x20, 0x29, 0x07, 0x59, 0xf0, 0xbc, 0xff, 0xab, 0xcf, 0x4e, 0x69, 0xbf} `2` through 10 = The default channel key, except with 1 through 9 added to the last byte |
+| channel_num | [uint32](#uint32) |  | NOTE: this field is _independent_ and unrelated to the concepts in channel.proto. this is controlling the actual hardware frequency the radio is transmitting on. In a perfect world we would have called it something else (band?) but I forgot to make this change during the big 1.2 renaming. Most users should never need to be exposed to this field/concept. A channel number between 1 and 13 (or whatever the max is in the current region). If ZERO then the rule is "use the old channel name hash based algorithm to derive the channel number") If using the hash algorithm the channel number will be: hash(channel_name) % NUM_CHANNELS (Where num channels depends on the regulatory region). NUM_CHANNELS_US is 13, for other values see MeshRadio.h in the device code. hash a string into an integer - djb2 by Dan Bernstein. - http://www.cse.yorku.ca/~oz/hash.html unsigned long hash(char *str) { unsigned long hash = 5381; int c; while ((c = *str++) != 0) hash = ((hash << 5) + hash) + (unsigned char) c; return hash; } |
+| psk | [bytes](#bytes) |  | A simple pre-shared key for now for crypto. Must be either 0 bytes (no crypto), 16 bytes (AES128), or 32 bytes (AES256) A special shorthand is used for 1 byte long psks. These psks should be treated as only minimally secure, because they are listed in this source code. Those bytes are mapped using the following scheme: `0` = No crypto `1` = The special "default" channel key: {0xd4, 0xf1, 0xbb, 0x3a, 0x20, 0x29, 0x07, 0x59, 0xf0, 0xbc, 0xff, 0xab, 0xcf, 0x4e, 0x69, 0xbf} `2` through 10 = The default channel key, except with 1 through 9 added to the last byte. Shown to user as simple1 through 10 |
 | name | [string](#string) |  | A SHORT name that will be packed into the URL. Less than 12 bytes. Something for end users to call the channel If this is the empty string it is assumed that this channel is the special (minimally secure) "Default"channel. In user interfaces it should be rendered as a local language translation of "X". For channel_num hashing empty string will be treated as "X". Where "X" is selected based on the English words listed above for ModemConfig |
 | id | [fixed32](#fixed32) |  | Used to construct a globally unique channel ID. The full globally unique ID will be: "name.id" where ID is shown as base36. Assuming that the number of meshtastic users is below 20K (true for a long time) the chance of this 64 bit random number colliding with anyone else is super low. And the penalty for collision is low as well, it just means that anyone trying to decrypt channel messages might need to try multiple candidate channels. Any time a non wire compatible change is made to a channel, this field should be regenerated. There are a small number of 'special' globally known (and fairly) insecure standard channels. Those channels do not have a numeric id included in the settings, but instead it is pulled from a table of well known IDs. (see Well Known Channels FIXME) |
 | uplink_enabled | [bool](#bool) |  | If true, messages on the mesh will be sent to the *public* internet by any gateway ndoe |
@@ -524,6 +524,7 @@ The other fields are either not sent at all, or sent in the special 16 byte LORA
 | hop_limit | [uint32](#uint32) |  | If unset treated as zero (no forwarding, send to adjacent nodes only) if 1, allow hopping through one node, etc... For our usecase real world topologies probably have a max of about 3. This field is normally placed into a few of bits in the header. |
 | want_ack | [bool](#bool) |  | This packet is being sent as a reliable message, we would prefer it to arrive at the destination. We would like to receive a ack packet in response. Broadcasts messages treat this flag specially: Since acks for broadcasts would rapidly flood the channel, the normal ack behavior is suppressed. Instead, the original sender listens to see if at least one node is rebroadcasting this packet (because naive flooding algorithm). If it hears that the odds (given typical LoRa topologies) the odds are very high that every node should eventually receive the message. So FloodingRouter.cpp generates an implicit ack which is delivered to the original sender. If after some time we don't hear anyone rebroadcast our packet, we will timeout and retransmit, using the regular resend logic. Note: This flag is normally sent in a flag bit in the header when sent over the wire |
 | priority | [MeshPacket.Priority](#MeshPacket.Priority) |  | The priority of this message for sending. See MeshPacket.Priority description for more details. |
+| rx_rssi | [int32](#int32) |  | rssi of received packet. Only sent to phone for dispay purposes. |
 
 
 
@@ -845,6 +846,8 @@ details on the type of failure).
 | NO_CHANNEL | 6 | No suitable channel was found for sending this packet (i.e. was requested channel index disabled?) |
 | TOO_LARGE | 7 | The packet was too big for sending (exceeds interface MTU after encoding) |
 | NO_RESPONSE | 8 | The request had want_response set, the request reached the destination node, but no service on that node wants to send a response (possibly due to bad channel permissions) |
+| BAD_REQUEST | 32 | The application layer service on the remote node received your request, but considered your request somehow invalid |
+| NOT_AUTHORIZED | 33 | The application layer service on the remote node received your request, but considered your request not authorized (i.e you did not send the request on the required bound channel) |
 
 
  

mesh.proto

@@ -230,6 +230,17 @@ message Routing {
      * (possibly due to bad channel permissions)
      */
     NO_RESPONSE = 8;
+
+    /*
+     * The application layer service on the remote node received your request, but considered your request somehow invalid
+     */
+    BAD_REQUEST = 32;
+
+    /*
+     * The application layer service on the remote node received your request, but considered your request not authorized (i.e you did not
+     * send the request on the required bound channel)
+     */
+     NOT_AUTHORIZED = 33;    
   }
 
   oneof variant {