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

Arbitrary service_name length limit #264

Open
RobinBol opened this issue Feb 21, 2024 · 3 comments
Open

Arbitrary service_name length limit #264

RobinBol opened this issue Feb 21, 2024 · 3 comments

Comments

@RobinBol
Copy link

Hi, what is the reason for ensuring the service_name length does not exceed 15 chars?

It seems rather arbitrary to me. I am running into issues for service_name's longer than 15 chars. Removing the checks above just seems to work as expected, it discovers the services.

@agnat
Copy link
Owner

agnat commented Feb 21, 2024

It's a requirement from RFC 6335. Also see http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt

@RobinBol
Copy link
Author

RobinBol commented Feb 21, 2024

Thanks for the quick reply! Unfortunately there are devices around with longer service names. Android TV's for example use a name with 16 chars (excluding leading underscore). They can be discovered on my Mac using Discovery (see below). Any chance that you would consider relaxing the 15 char limit somewhat?

Screenshot 2024-02-21 at 17 17 19

It also seems the avahi-daemon has no problem discovering the longer service names.

@agnat
Copy link
Owner

agnat commented Feb 24, 2024

Increasing the max length is not a solution. While it works for this string it will fail for others. This is uff-8 and a character may require up to 32 bits.

I might take a PR that turns the max length (and the charset) into a user setting. That way people can work around illegal identifiers but not without noticing that something is fishy.

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