Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chaining multiple routers #1

Open
craigerl opened this issue Dec 13, 2019 · 7 comments
Open

chaining multiple routers #1

craigerl opened this issue Dec 13, 2019 · 7 comments

Comments

@craigerl
Copy link

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

@iddq
Copy link
Owner

iddq commented Dec 15, 2019

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

@craigerl
Copy link
Author

craigerl commented Dec 15, 2019 via email

@iddq
Copy link
Owner

iddq commented Dec 15, 2019

Do you have the output of axdigi2018 from BERR37?

@craigerl
Copy link
Author

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.

@iddq
Copy link
Owner

iddq commented Dec 15, 2019

ok I've found something, I think the interface index was zero. Fix is coming soon.

@craigerl
Copy link
Author

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.

@iddq
Copy link
Owner

iddq commented Dec 17, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants