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

Please replace the default lora_pkt_fwd #37

Open
vaugss opened this issue Oct 24, 2020 · 1 comment
Open

Please replace the default lora_pkt_fwd #37

vaugss opened this issue Oct 24, 2020 · 1 comment

Comments

@vaugss
Copy link

vaugss commented Oct 24, 2020

Several people are facing problems with the default lora_pkt_fwd packet forwarder when using the gateway with OTAA end nodes and chirpstack.
The problem consists in a JoinRequest and JoinAccept loop where the packet forwarder doesn't send the JoinAccept ACK message back to the end nodes.
This problem was solved by replacing the defaut packet forwarder for mp_pkt_fwd, provided by Jac Kersing (https://github.com/kersing/packet_forwarder).

This solution was validated by more people in chirpstack forum.
I validated it using the latest available RAK 7246G firmware, in October 24, 2020.

@cstratton
Copy link

cstratton commented Jan 15, 2021

You are free to run whatever packet forwarder you like, however in terms of the this public repo, a request to wholesale replace one thing with another, with no specific justification given, is not really how software projects evolve.

Both the packet forwarder here and Kersing's are derived from the Semtech reference code; the version here is quite a bit closer to it, in that much of the code is literally checkout out from Semtech's own repos at build time, with only a few key files modified by RAK in ways that you could readily diff against their upstream originals.

If you have found a specific behavioral issue with the version here, then please document what exactly that undesired behavior is - what happens, under what conditions, and how does that differ from what you believe should happen? Such a report needs to be specific about the behavior of the gateways itself, not vague and involving the node. Eg - when given the following exactly copied transmit request by the network server, this happens, but we believe this other thing should happen instead.

Alternately, if you can point to a specific bugfix commit in Kersing's repository which you believe should prompt a similar change here, then please specifically identify it and explain the circumstances where it is important. You may also want to file that upstream with Semtech if the behavior comes directly from there, and is not in the portion of the code overridden by the contents of this repo.

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