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

Don't process/forward packets from repeater if RF call sign is blank. #51

Open
coolacid opened this issue Sep 7, 2024 · 7 comments
Open

Comments

@coolacid
Copy link

coolacid commented Sep 7, 2024

It seems the RF side call signs seem to be missing in for the Repeater header at least when connected to icom repeater gear.

2024-09-07 23:25:22: Repeater header - My:         /      Your:        E  Rpt1: VE3LSR C  Rpt2: VE3LSR G  Flags: 00 00 00 (172.16.0.1:20000)
2024-09-07 23:29:49: Repeater header - My:         /      Your:        I  Rpt1: VE3LSR B  Rpt2: VE3LSR G  Flags: 00 00 00 (172.16.0.1:20000)
2024-09-07 23:32:51: Repeater header - My:         /      Your: CQCQCQ    Rpt1: VE3LSR B  Rpt2: VE3LSR G  Flags: 00 00 00 (172.16.0.1:20000)
@coolacid
Copy link
Author

coolacid commented Sep 7, 2024

When I connect the system to my URFd reflector I see the following, so it seems the call sign isn't being sent out the wire too.

cluster2-urfd-1  | Unknown DCS packet from 208.80.103.141:
cluster2-urfd-1  | 0000:  30 30 30 31 00 00 00 58 4C 58 43 41 31 20 41 56    *0001...XLXCA1 AV*
cluster2-urfd-1  | 0010:  45 33 4C 53 52 20 43 43 51 43 51 43 51 20 20 20    *E3LSR CCQCQCQ   *
cluster2-urfd-1  | 0020:  20 20 20 20 20 20 20 20 20 20 20 85 10 08 26 C2    *           ...&.*
cluster2-urfd-1  | 0030:  08 22 A4 23 79 37 E6 50 0C D0 71 00 00 01 00 21    *.".#y7.P..q....!*
cluster2-urfd-1  | 0040:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    *................*
cluster2-urfd-1  | 0050:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    *................*
cluster2-urfd-1  | 0060:  00 00 00 00                                        *....*

@coolacid
Copy link
Author

coolacid commented Sep 7, 2024

And, just as I write that last comment, a different user started using the system and their callsign shows up fine.

@coolacid
Copy link
Author

coolacid commented Sep 8, 2024

Never mind, my radio somehow changed to a local call that was configured to be blank.

I'm going to leave this open as I suspect if the call sign is blank, either the packet shouldn't be processed, or at the very least shouldn't be forwarded to reflectors.

@coolacid coolacid changed the title Missing details from Headers.log Don't process/forward packets from repeater if RF call sign is blank. Sep 8, 2024
@F4FXL
Copy link
Owner

F4FXL commented Sep 10, 2024

Thanks for the heads up. This behavior is the same as in ircddbGateway. IMHO it is better to forward to the reflector maybe the operator might get a reply from other that his radio his misconfigured.

@coolacid
Copy link
Author

Since there's no operator call sign in the DStar data packet, neither the repeater, nor the reflector has any contact details to work with. I don't know the DStar RF spec, but in reality, if there's no CallSign set, I'd expect the repeater to return some kind of error.

Makes me wonder what the ICOM service would have done.

@F4FXL
Copy link
Owner

F4FXL commented Sep 12, 2024

Well, the audio will make it through end other operators on the other end might be able to signal the issue to the "blank station" via voice.
Maybe this should addressed at the modem ie. MMDVMHost level rather than gateway level ? Maybe the gateway should never ever see such frames?

@coolacid
Copy link
Author

Yeah, maybe the gateway shouldn't see the frames. I'm on iCOM gear so it sends the frames to the controller, which in my case is the gateway. I'll do some more experiments with my team here to see what happens. I can't test the iCOM gateway tho.

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