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

lbt_cfg prevents some gateways from operating #28

Open
terrillmoore opened this issue Jan 25, 2018 · 3 comments
Open

lbt_cfg prevents some gateways from operating #28

terrillmoore opened this issue Jan 25, 2018 · 3 comments
Assignees

Comments

@terrillmoore
Copy link
Contributor

For AS2, Japan requires LBT. But Taiwan does not.

Currently, the as2 config includes LBT overrides. This means that gateways in Taiwan without LBT support in hardware can't use the as2 config, even though they're otherwise fine.

Please consider further splitting for AS2 with and without LBT.

(I also note that AS1 always enforces LBT, and I'm not sure that this is needed in every country.)

@johanstokking johanstokking self-assigned this Jan 25, 2018
@johanstokking
Copy link
Member

Thanks for raising this issue and the suggestion.

Would a (temporary) solution indeed be having LBT/non-LBT alternatives available for those plans If so, can you file a PR?

BTW, this will be addressed with the V3 Gateway Agent, but that's a whole different approach than using today's UDP Packet Forwarder derivatives.

@terrillmoore
Copy link
Contributor Author

Would a (temporary) solution indeed be having LBT/non-LBT alternatives available for those plans If so, can you file a PR?

Certainly for my cases, that would work. I will file a pull request.

We need to think through compatibility issues.

Since LBT doesn't wok on the older gateways, we can safely assume that nobody is using the current as2 config with older gateways. So the least risk approach is to introduce a new non-LBT family (AS2-nolbt?) of conf files. I have not checked every country that uses as1, but it probably makes sense also to introduce as1-nolbt.

An alternative would be to add specific country entries as needed; then have "AS2-tw", etc.

Or could just create "TW-global_conf.json".

  • Using a name that includes "nolbt" is easy technically but probably hard for users who don't understand bandplans, but know where the gateway is going to be installed.

  • Using a name with a country code requires that we do additional changes on a country-by-country basis, and I don't have the ability to research all the variants at the moment.

At the moment, with Jeff Honig's Ansible installer, we have the option of fixing this during the merge, so I personally could just patch this during install. But I think that's not a good idea generally speaking.

I'll mull this over, but lean toward creating "TW-global_conf.json"

BTW: I am not sure what to do about configs.txt and the .yml files. It appears that configs.txt is out of date, so not sure if the .yml file also needs an update. Since it's already out of date, I think that's a separate issue.

@johanstokking
Copy link
Member

Yes I think country codes is fine!

I think the yml is fine to update.

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