Open craigerl opened 4 years ago
Hi Craig, thanks for your feedback. Can you please check this issue again if you assign different callsigns to the machines? Please rename KM6LYW-10 to something different because it is the same callsign than KM6LYW even if the SSID is different. If this is the case then I will think about a solution. 73
heh, well, I can't, not legally anyhow. I know that sounds silly . This isn't a show stopper as it's a rare scenario (multiple hops in route). I just thought I'd mention for the next time you have the source open.
thanks! -craig
On 12/15/19 2:45 AM, Gabor wrote:
Hi Craig, thanks for your feedback. Can you please check this issue again if you assign different callsigns to the machines? Please rename KM6LYW-10 to something different because it is the same callsign than KM6LYW even if the SSID is different. If this is the case then I will think about a solution. 73
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/iddq/axdigi2018/issues/1?email_source=notifications&email_token=AFIEHVS7JUBNYMT56VHYCPDQYYDFBA5CNFSM4J2P6JIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4WGFQ#issuecomment-565797654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFIEHVU5GIE37E6RG56WCP3QYYDFBANCNFSM4J2P6JIA.
Do you have the output of axdigi2018 from BERR37?
the only stdout from axdigi2018 I have is in the original post. I can only reach it on rare occasions, making debugging nearly impossible here.
ok I've found something, I think the interface index was zero. Fix is coming soon.
just to be sure, and i know this gets confusing real fast, but this is my process
KM6LYW trys to reach K6WLS-10 via BERR37 then KM6LYW-10
That's three hops through two routers. If KM6LYW-10 (axdigi) doesn't retain the asterisk on BERR37, as well adding an asterisk to itself, I'm concerned we'll get an infinite loop and BERR37 will repeat the packet again.
I tried exactly the same setup in VMs and I could not reproduce the issue.
KM6LYW is calling K6WLS-10 via BERR37 KM6LYW-10
/usr/src/ax25-apps/call/call KM6LYW K6WLS-10 via BERR37 KM6LYW-10
The strangest part is there is no code that would remove the existing repeated flag from any digi field.
I checked the interface index numbering and it cannot be zero. So this should be not a problem.
I did a small modification. axdigi2018 did not show asterisk at own callsign even if the repeated flag is set correctly in the outgoing packet. This is why I update the parsed header data after modifying the packet for digipeating.
Please try to reproduce the issue and capture the traffic by axlisten -a -h on both hosts.
Regarding to the loop protection:
If digi field has disabled repeated flag before a digi field has enabled repeated flag then the packet is silently ignored.
The packet will only be digipeated if the first digi without repeated flag in the list is one of our interface callsign.
Should the asterisk not be retained if we're in a chain of digipeaters?
When we digipeat the packet, should we keep the asterisk next to BERR37*? along with adding the asterisk to our own callsign? Wont BERR37 digipeat it again after we digipeat?
No idea how ax.25 spec works, so just asking, thanks, -craig
axdigi2018 (2017-DEC-06). Copyright (C) 1995 Craig Small VK2XLZ, 2017 Gabor Mayer HG5OAP
port[0]: interface: ax0, index: 3, callsign: KM6LYW-10 beacon: path: -> BEACON via RFONLY beacon: text: AX.25 packet radio digipeater beacon: interval: 300 KM6LYW -> K6WLS-10 via BERR37, KM6LYW-10 KM6LYW -> AG6QO-10 via BERR37, KM6LYW-10
TNC.......................... Digipeater BERR37 audio level = 53(26/10) [NONE] ___|| [0.7] KM6LYW>K6WLS-10,BERR37,KM6LYW-10:(DISC cmd, p=1) [0H] KM6LYW>K6WLS-10,BERR37,KM6LYW-10:(DISC cmd, p=1) <<< EXPECT * after BERR37? [0L] KM6LYW-10>BEACON,RFONLY:AX.25 packet radio digipeater