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

Strange behavior of actual YSFReflector with DMR-Bridge on BrandMeister #254

Open
dg9vh opened this issue Feb 28, 2021 · 4 comments
Open

Comments

@dg9vh
Copy link
Contributor

dg9vh commented Feb 28, 2021

Copy of my E-Mail to the Mailinglist:

Hi,

I don't know if it is an issue of the YSFReflector or if it is an issue of the BrandMeister YSFClient-connection to the reflectors but:
If you use actual version of YSFReflector (actual since about 2 weeks with blocking abilities built in by Jonathan) it is working perfectly from YSF to YSF. But if you have an interconnected Reflector that uses YSFClient-Connection from BrandMeister to get connected to a TG there traffic originated at YSF side will sound stretched and repeatingly on DMR... an effect we had on first attempts of the blocking list but removed them... It's only persistent with actual version.

So if someone also has this effects, please report them for further testing... I think there is something little odd in the code that the DMR-Bridges don't like so much.

Bad thing is that I can't test it myself because I only have one hotspot and when using it with YSF I only can check with blueDV and AMBE-Stick on DMR and then all sounds ok strangely.

73 de Kim
DG9VH

So I sadly can't reproduce this alone, that's the fact why I did not report it while I was testing the version two weeks ago...

Hope someone is responding to help us testing this :-)

@g4klx
Copy link
Owner

g4klx commented Feb 28, 2021

The network hasn't changed at all. Is it possible that someone is interpreting the sequence number incorrectly? The sequence number is a byte with the end of message bit being 0x01. The rest of the byte is used as the sequence number is the remaining seven bits. It was a silly design decision I know.

If you interpret the byte as a simple sequence number you will get 0, 2, ,4 , 6, etc. So your software would presumably fill in the gaps. So the byte needs to be shifted to the right one bit to get the sequence number and the byte ANDed with 0x01 to get the end of message indication.

@dg9vh
Copy link
Contributor Author

dg9vh commented Feb 28, 2021

That's my idea, too... the BrandMeister YSFClient is causing the problem here :-) will wait, what the BM-guys say... I asked in their telegram-support-group... but still no reply...

@g4klx
Copy link
Owner

g4klx commented Feb 28, 2021

They'll blame me as usual.

@cyanide-burnout
Copy link

All good with the sequence numbers. From time to time Reflector creates at least the second connection context for the same srcip:srcport. Probably when reflector is behind the NAT.

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

3 participants