search

meshtastic / firmware

Meshtastic device firmware
https://meshtastic.org
GNU General Public License v3.0
3.33k stars 810 forks source link

[Bug]: Direct messages (directed to a certain station) are not re-broadcasted in mesh #1459

Closed ernax78 closed 2 years ago

ernax78 commented 2 years ago

Category

Other

Hardware

Not Applicable

Firmware Version

1.2.64

Description

After discussing with @andrekir on Discord, it seems this bug is not addressed in 1.3 either so here it goes;

If you send a direct message it will not be re-broadcasted in the mesh, it will just send directly from the sending station and not "bounce" via MQTT nor other re-broadcast via other stations.

To reproduce: Send a DM that does not have direct radio connection with the sending station. If you send a "broadcast" it will get the message (via MQTT / re-broadcast) If you send the DM, it will not be recieved.

Log output snatched from AndreK at Discord

Relevant log output

broadcast (To0xff)

13:40:42 92934 [RadioIf] (bw=250, sf=11, cr=4/8) packet symLen=8 ms, payloadSize=25, time 665 ms
13:40:42 92934 [RadioIf] Lora RX (id=0xec7f6477 Fr0xbc To0xff, WantAck0, HopLim3 Ch0x8 encrypted rxSNR=6.75 rxSNR=1.52895e-154)
13:40:42 92934 [RadioIf] AirTime - Packet received : 665ms
13:40:42 92934 [Router] Add packet record (id=0xec7f6477 Fr0xbc To0xff, WantAck0, HopLim3 Ch0x8 encrypted rxSNR=6.75 rxSNR=1.52895e-154)
13:40:43 92935 [Router] Using channel 0 (hash 0x8)
13:40:43 92935 [Router] Expanding short PSK #1
13:40:43 92935 [Router] Installing AES128 key!
13:40:43 92935 [Router] decoded message (id=0xec7f6477 Fr0xbc To0xff, WantAck0, HopLim3 Ch0x0 Portnum=3 rxtime=1652881243 rxSNR=6.75 rxSNR=1.52895e-154)
13:40:43 92935 [Router] handleReceived(REMOTE) (id=0xec7f6477 Fr0xbc To0xff, WantAck0, HopLim3 Ch0x0 Portnum=3 rxtime=1652881243 rxSNR=6.75 rxSNR=1.52895e-154)
13:40:43 92935 [Router] Module 'position' wantsPacket=1
13:40:43 92935 [Router] Received position from=0xbdf0bebc, id=0xec7f6477, portnum=3, payloadlen=5
13:40:43 92935 [Router] POSITION node=bdf0bebc l=5 TIME 
13:40:43 92935 [Router] updatePosition SPECIAL time setting time=1652881228
13:40:43 92935 [Router] Node status update: 1 online, 2 total
13:40:43 92935 [Router] Module 'position' considered
13:40:43 92935 [Router] Module 'routing' wantsPacket=1
13:40:43 92935 [Router] Received routing from=0xbdf0bebc, id=0xec7f6477, portnum=3, payloadlen=5
13:40:43 92935 [Router] Routing sniffing (id=0xec7f6477 Fr0xbc To0xff, WantAck0, HopLim3 Ch0x0 Portnum=3 rxtime=1652881243 rxSNR=6.75 rxSNR=1.52895e-154)
13:40:43 92935 [Router] Rebroadcasting received floodmsg to neighbors (id=0xec7f6477 Fr0xbc To0xff, WantAck0, HopLim3 Ch0x0 Portnum=3 rxtime=1652881243 rxSNR=6.75 rxSNR=1.52895e-154)
13:40:43 92935 [Router] Expanding short PSK #1
13:40:43 92935 [Router] Installing AES128 key!
13:40:43 92935 [Router] enqueuing for send (id=0xec7f6477 Fr0xbc To0xff, WantAck0, HopLim2 Ch0x8 encrypted rxtime=1652881243 rxSNR=6.75 rxSNR=1.52895e-154)
13:40:43 92935 [Router] txGood=1554,rxGood=1505,rxBad=1
13:40:43 92935 [Router] rx_snr found. hop_limit:2 rx_snr:6.750000
13:40:43 92935 [Router] rx_snr found in packet. Setting tx delay:1002
13:40:43 92935 [Router] FIXME-update-db Sniffing packet
13:40:43 92935 [Router] Delivering rx packet (id=0xec7f6477 Fr0xbc To0xff, WantAck0, HopLim3 Ch0x0 Portnum=3 rxtime=1652881243 rxSNR=6.75 rxSNR=1.52895e-154)
13:40:44 92936 [Router] Forwarding to phone (id=0xec7f6477 Fr0xbc To0xff, WantAck0, HopLim3 Ch0x0 Portnum=3 rxtime=1652881243 rxSNR=6.75 rxSNR=1.52895e-154)
13:40:44 92936 [Router] Update DB node 0xbdf0bebc, rx_time=1652881243
13:40:44 92936 [Router] Module 'routing' considered

direct message (To0xff)

13:36:53 92705 [RadioIf] (bw=250, sf=11, cr=4/8) packet symLen=8 ms, payloadSize=32, time 747 ms
13:36:53 92705 [RadioIf] Lora RX (id=0xa3590a6e Fr0xbc To0xb2, WantAck1, HopLim3 Ch0x8 encrypted rxSNR=6 rxSNR=1.52895e-154)
13:36:53 92705 [RadioIf] AirTime - Packet received : 747ms
13:36:54 92706 [Router] Add packet record (id=0xa3590a6e Fr0xbc To0xb2, WantAck1, HopLim3 Ch0x8 encrypted rxSNR=6 rxSNR=1.52895e-154)
13:36:54 92706 [Router] Using channel 0 (hash 0x8)
13:36:54 92706 [Router] Expanding short PSK #1
13:36:54 92706 [Router] Installing AES128 key!
13:36:54 92706 [Router] decoded message (id=0xa3590a6e Fr0xbc To0xb2, WantAck1, HopLim3 Ch0x0 Portnum=1 rxtime=1652881014 rxSNR=6 rxSNR=1.52895e-154)
13:36:54 92706 [Router] handleReceived(REMOTE) (id=0xa3590a6e Fr0xbc To0xb2, WantAck1, HopLim3 Ch0x0 Portnum=1 rxtime=1652881014 rxSNR=6 rxSNR=1.52895e-154)
13:36:54 92706 [Router] Module 'routing' wantsPacket=1
13:36:54 92706 [Router] Received routing from=0xbdf0bebc, id=0xa3590a6e, portnum=1, payloadlen=12
13:36:54 92706 [Router] Routing sniffing (id=0xa3590a6e Fr0xbc To0xb2, WantAck1, HopLim3 Ch0x0 Portnum=1 rxtime=1652881014 rxSNR=6 rxSNR=1.52895e-154)
13:36:54 92706 [Router] FIXME-update-db Sniffing packet
13:36:54 92706 [Router] Module 'routing' considered
ernax78 commented 2 years ago

GUVWAF — Yesterday at 11:32 PM I guess it has to do with this line: https://github.com/meshtastic/Meshtastic-device/blob/master/src/mesh/FloodingRouter.cpp#L33 Fixing it might be as easy as changing '== NODENUM_BROADCAST' into '!= getNodeNum()'.

GUVWAF commented 2 years ago

Did you by any chance build the firmware on your devices from source? I can confirm that with the above modification normal flooding still works, but since I have only two nodes, I cannot verify rebroadcasting using a DM (since a node will not rebroadcast a packet destined for itself). I am pretty confident that it will work, so you might give it a try.

charminULTRA commented 2 years ago

I probably have something setup wrong, but can't compile 1.2.64 to test this edit, strangely I can compile 1.3 fine, but I can't use that yet until the web and iOS updates are made.

ernax78 commented 2 years ago

I have tested this on my setup in the office now and it is almost as you wrote.

My setup: Office: T-Echo (1.2.64) -> Modified T-Lora (1.2.50) ----- MQTT ------> T-Beam (1.2.64)

With unmodified firmware - no messages are forwarded

With the modification you proposed - no messages are forwarded when doing DM due to the fact it seems HopLimit = 0 on DMs

With the "Ugly fix" below (do not do it - it will cause your device to go in to a boot loop due to assert error) the DMs are indeed forwarded to my T-beam over MQTT, however I do not get an "ack" it has been recieved from the T-beam

if (p->to != getNodeNum() && p->hop_limit >= 0 && getFrom(p) != getNodeNum())

Conclusion is this "bug" goes deeper than this simple fix and possibly needs some architectural thought.

Next test would be to try to send DM where HopLimit is not 0, I have not found that in the code yet, maybe someone can give me a pointer.

Also, with the upcoming 1.3, I dont know if it is wise to continue testing on the 1.2 branch if there are some changes done on routing on 1.3 from 1.2.

GUVWAF commented 2 years ago

@ernax78 You can let the device set the default hop_limit (which is 3) also on a DM by removing "p->to == NODENUM_BROADCAST &&" on this line.

Regarding ACKs not being sent back: I think this is 'normal' behavior, since ACKs are not rebroadcasted (reaching only immediate neighbors is assumed here) and thus the ACK sent by your T-beam will not end up on the T-Echo.

I think for these specific routing settings, nothing has changed on 1.3 with respect to 1.2, so you can continue testing on 1.2.

garthvh commented 2 years ago

The ack is only sent to the node that sent the DM