Skip to content

DNS_MAX_NAME_LENGTH changed from lwip 1.4 to 2.0 #5799

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

Closed
reglos opened this issue Feb 21, 2019 · 6 comments
Closed

DNS_MAX_NAME_LENGTH changed from lwip 1.4 to 2.0 #5799

reglos opened this issue Feb 21, 2019 · 6 comments
Assignees

Comments

@reglos
Copy link

reglos commented Feb 21, 2019

DNS_MAX_NAME_LENGTH for lwip v1.4 "Higher Bandwith" is defined as 256.
In lwip v2.0 it is set to 128 for all variants.

As RFC1035 allows for dns hostnames up to 255 bytes, there should be an option to address these.
I suggest setting it to 256 for all the "higher bandwith" lwip variants and leave it at 128 for the "lower memory" options.

Why not stay with 1.4 "Higher Bandwith"? There is a bug in lwip 1.4. After several hundered dns requests it suddenly starts to send out random garbage udp packets to the dns-server as I can see in the logfiles of my nameserver and verified by wireshark.

@d-a-v
Copy link
Collaborator

d-a-v commented Feb 21, 2019

This is an harcoded parameter in lwIP, that was lowered because it takes this ram multiplied by the number of entries in the dns client cache.
Do you need fqdn with more than 128 bytes ?

@reglos
Copy link
Author

reglos commented Feb 21, 2019

Yes, I have to lookup addresses in a subnet which can use the full possible namelength permitted by RFC1035. Took me quite a while to find out why my sketch worked on all test-cases (short names) but when deployed failed on some occasions, because I didn't expect non-conformant behaviour of a basic network functionality.

Can lwip v2 somehow be compiled with a
#define DNS_MAX_NAME_LENGTH 256 ?
and a very small cache size?

@d-a-v
Copy link
Collaborator

d-a-v commented Feb 21, 2019

Maybe it's time for #3740 (comment)

In the meantime you can locally recompile lwip2 with this updated limitation.

cd tools/sdk/lwip2
make download
cd builder/glue-lwip/arduino
vi lwipopts.h      (DNS_MAX_NAME_LENGTH line 1108)
cd ../../..
make install

@d-a-v d-a-v self-assigned this Feb 21, 2019
@devyte
Copy link
Collaborator

devyte commented Feb 21, 2019

@d-a-v I agree about the comment in #3740.
@reglos you are the first user ever since lwip2 was integrated to encounter this. The precompiled lwip used by the core won't be changed for full rfc conformance, because it reduces available heap for every other user, and they don't need it. Also, you do have the option to build your own custom lwip, as @d-a-v explained.
However, we'll pursue the solution referenced above with lwip upstream and bring it in later on. That would be the best of both worlds, I think.

@reglos
Copy link
Author

reglos commented Feb 21, 2019

Thanks @d-a-v, compiling lwip2 with modified defines worked fine for me. I had been searching quite a while for the recipe... I had to install the git version first, correct? In the boards manager version I did not find the lwip2 sources. Are there any problems to expect, having both versions now installed in the Arduino IDE?

@ devyte The application is indeed rather exotic, but there are applications where you want to put a lot of information into a hostname. Until the dynamic allocation makes it into lwip2, I am fine with compiling myself.

@d-a-v
Copy link
Collaborator

d-a-v commented Nov 9, 2020

I am fine with compiling myself.

👍

@d-a-v d-a-v closed this as completed Nov 9, 2020
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