strange behaviour with multiple digipeaters close together about lora_aprs_igate

[peterus]

@dg0tm do you have time to take a look? thanks!

[on1arf]

HI,

Do you mean that the issue should be solved? Has the change been commited?
I can ask the ham's here in Oostende to flash their node with the new software and redo the check.

Looking at the code-changes, I do not know if this is the issue.
The changes are related to solving loops on the aprs routing-level, but

• In that case, I would expect the aprs path to grow in every digipeated packet, and the logfile do not show this.
• the issue does not happen every time, and even if it does, the number of times the packet is repeated changes.
  If this would be a pure 'logical' bug, I would expect the issue to be much more 'predictive' and not so random.

Perhaps it is related to have the sx1276 chip reacts when -at the end of a transmission- it detect that there is also another lora-transmitter active. Does the chip do a CAD-check after a transmission?

73
kristoff - on1arf

[peterus]

@on1arf the issue should be resolved in the developer branch. can you get in contact with your local hams and ask them to reflash with the latest developer version? thank you very much!

[on1arf]

Hi, I had just adapted me previous message. I will ask the local hams to do the change and flash their device.
I will also try to go on site and take some on-air snapshots to check what is really transmitter and by what station.

But as said, I am not sure if this is just a 'logic' bug

[on1arf]

Hi,

I am still waiting for my fellow local hams to upgrade the firmware of their igate (yes, summer :-) ).

But I did some more experiments, and I think I found the issue. As far as I can see, the issue is related to how the digipeater changes the aprs routing-path in the packets in relays.

Setup:
my station (ON1ARF-0), 2 lora digipeaters at 8 km (ON1TG-13 and ON4AM-10), 1 igate (ON1TG-14)
micropython application on my station that transmits lora-packets and dumps lora-packets it receives
I transmit at low power (3 dm), so only one of the digipeaters (ON1TG-13) is able to receive me directly!

The tests: (lines starting with 'S' is what I sent, starting with 'R' is what is being received)

• test 1:
  S APLT00-1:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32
  R APLT00-1,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32
  R APLT00-1,ON4AIM-10*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32
  (repeating)

Take note of the 2nd packet (from ON4AIM-10). It receives it from ON1TG-13 (as on4AIM-10 cannot receive me directly), but the path of that packet only contains ON4AIM-10*, not ON1TG-13*,ON4AIM-10*

• Test 2:
  S APLT00,WIDE1-1:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32
  R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32
  (...)
  ON1TG-13 seams to have changed the path of the packet, replacing the 'WIDE1-1' with its callsign!
  Again, the packet goes into a loop between ON1TG-13 and ON4AIM-10

• test 3:
  S APLT00,ON1ARF-2*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32
  R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32
  (...)
  Same thing as above: ON1TG-13 seams to have changed the path of the packet, replacing whatever I place inthere with its callsign!

• test 4:
  S APLT00,ON1ARF-2*,ON1ARF-3*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32
  R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32
  (...)
  Same thing as above.

It all seems to point to the same problem: the digipeater software does not append its callsign to the APRS path, but replaces what ever is already in the path (even longer paths) by its own callsign.
If you do this in an environment where multiple digipeaters are active, this will break the aprs-routing 'loop-protection'.

If I look at the bugfix #99, I do not think that that fix will solve this issue.

Kristoff - ON1ARF

[dg0tm]

Hi, we backing on you. The logic is only repeat if WIDE1-1 is in path and replace the path without WIDE by only DIGI Call. Than it should be no more repeatet take place. I will build an test setup to make my one tests to morrorow. 73 de DG0TM Am 29.07.21 um 20:22 schrieb Kristoff Bonne:

…

Hi, I am still waiting for my fellow local hams to upgrade the firmware of their igate (yes, summer :-) ). But I did some more experiments, and I think I found the issue. As far as I can see, the issue is related to how the digipeater changes the aprs routing-path in the packets in relays. Setup: my station (ON1ARF-0), 2 lora digipeaters at 8 km (ON1TG-13 and ON4AM-10), 1 igate (ON1TG-14) micropython application on my station that transmits lora-packets and dumps lora-packets it receives I transmit at low power (3 dm), so only one of the digipeaters (ON1TG-13) is able to receive me directly! The tests: (lines starting with 'S' is what I sent, starting with 'R' is what is being received) * test 1: S APLT00-1:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00-1,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00-1,ON4AIM-10*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 (repeating) Take note of the 2nd packet (from ON4AIM-10). It receives it comes from from ON1TG-13 (as on4AIM-10 cannot receive me directly), but the path of that packet only contains ON4AIM-10*, not ON1TG-13*,ON4AIM-10* * Test 2: S APLT00,WIDE1-1:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 (...) ON1TG-13 seams to have changed the path of the packet, replacing the 'WIDE1-1' with its callsign! Again, the packet goes into a loop between ON1TG-13 and ON4AIM-10 * test 3: S APLT00,ON1ARF-2*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 (...) Same thing as above: ON1TG-13 seams to have changed the path of the packet, replacing whatever I place inthere with its callsign! * test 4: S APLT00,ON1ARF-2*,ON1ARF-3*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 (...) Same thing as above. It all seems to point to the same problem: the digipeater software does not append its callsign to the APRS path, but replaces what ever is already in the path (even longer paths) by its own callsign. If you do this in an environment where multiple digipeaters are active, this will break the aprs-routing 'loop-protection'. If I look at the bugfix #99 <#99>, I do not think that that fix will solve this issue. Kristoff - ON1ARF — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZZ3OYSGGF6OCGVQ4GTIQLT2GL43ANCNFSM5AMDZQUQ>.

[on1arf]

Halle, If you need  help, feel free to let me know. I have two 't-beam' devices, a LiliGo t3 and a seperation board with a RFM82, so I can test if needed. I can easily craft packets in any format as needed. I am on matrix ***@***.***) and on DMR. Kr.

…

On 31.07.21 23:30, dg0tm wrote: Hi, we backing on you. The logic is only repeat if WIDE1-1 is in path and replace the path without WIDE by only DIGI Call. Than it should be no more repeatet take place. I will build an test setup to make my one tests to morrorow. 73 de DG0TM Am 29.07.21 um 20:22 schrieb Kristoff Bonne: > > Hi, > > I am still waiting for my fellow local hams to upgrade the firmware of > their igate (yes, summer :-) ). > > But I did some more experiments, and I think I found the issue. As far > as I can see, the issue is related to how the digipeater changes the > aprs routing-path in the packets in relays. > > Setup: > my station (ON1ARF-0), 2 lora digipeaters at 8 km (ON1TG-13 and > ON4AM-10), 1 igate (ON1TG-14) > micropython application on my station that transmits lora-packets and > dumps lora-packets it receives > I transmit at low power (3 dm), so only one of the digipeaters > (ON1TG-13) is able to receive me directly! > > The tests: (lines starting with 'S' is what I sent, starting with 'R' > is what is being received) > > * test 1: > S APLT00-1:!5114.02N/00258.56E-testing APRS over Lora running > micropython on a ESP32/lora32 > R APLT00-1,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora > running micropython on a ESP32/lora32 > R APLT00-1,ON4AIM-10*:!5114.02N/00258.56E-testing APRS over Lora > running micropython on a ESP32/lora32 > (repeating) > > Take note of the 2nd packet (from ON4AIM-10). It receives it comes > from from ON1TG-13 (as on4AIM-10 cannot receive me directly), but the > path of that packet only contains ON4AIM-10*, not ON1TG-13*,ON4AIM-10* > > * > > Test 2: > S APLT00,WIDE1-1:!5114.02N/00258.56E-testing APRS over Lora > running micropython on a ESP32/lora32 > R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora > running micropython on a ESP32/lora32 > (...) > ON1TG-13 seams to have changed the path of the packet, replacing > the 'WIDE1-1' with its callsign! > Again, the packet goes into a loop between ON1TG-13 and ON4AIM-10 > > * > > test 3: > S APLT00,ON1ARF-2*:!5114.02N/00258.56E-testing APRS over Lora > running micropython on a ESP32/lora32 > R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora > running micropython on a ESP32/lora32 > (...) > Same thing as above: ON1TG-13 seams to have changed the path of > the packet, replacing whatever I place inthere with its callsign! > > * > > test 4: > S APLT00,ON1ARF-2*,ON1ARF-3*:!5114.02N/00258.56E-testing APRS over > Lora running micropython on a ESP32/lora32 > R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora > running micropython on a ESP32/lora32 > (...) > Same thing as above. > > It all seems to point to the same problem: the digipeater software > does not append its callsign to the APRS path, but replaces what ever > is already in the path (even longer paths) by its own callsign. > If you do this in an environment where multiple digipeaters are > active, this will break the aprs-routing 'loop-protection'. > > If I look at the bugfix #99 > <#99>, I do not > think that that fix will solve this issue. > > Kristoff - ON1ARF > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#99 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACZZ3OYSGGF6OCGVQ4GTIQLT2GL43ANCNFSM5AMDZQUQ>. > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGUBK3DTWN4SLWWSZAR52DT2RTODANCNFSM5AMDZQUQ>.

[on1arf]

Hi, Is the bugfix for this issue already implemented?

Kr.

[dg0tm]

For now only in dev branch! 73 de DG0TM Am 18.08.2021 um 20:26 schrieb Kristoff Bonne:

…

Hi, Is the bugfix for this issue already implemented? Kr. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZZ3O3VBPMYTSAJZ4E5KCLT5P3OHANCNFSM5AMDZQUQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>.