First (critical)
Any TinyCLR device connected to a network with a DHCP server is registered with the server named “lwip”.
The following situation is created (example):
- Connected “YOUR Device”, received 192.168.0.133 and mapped the name “lwip”.
- On the remote computer, we search for the name associated with this IP. We get the name “lwip”. “Good” we think and work with him by this name (although we have an implementation of the NetBIOS Name Service, but don’t care).
- After some time, your office neighbor connects “HIS Device” to the local network on TinyCLR. His device also receives the address (192.168.0.209), and at the same time matches the name “lwip” with it.
- But you still continue to work with the name “lwip” which is given to “YOUR Device”. Unaware that another device has already hijacked that name. This is a failure…
All devices named “lwip” belong to TinyCLR.
This is due to the fact that when sending the “DHCP REQUEST” packet to the DHCP server, the device on the TinyCLR sends a “(12) Host Name” field with the constant name “lwip”.
The NetMF did not send this field.
So a fix is needed. There are two options here:
- Allow the user to set “Hostname” for the lwip driver.
- Or exclude the transmission of the “(12) Host Name” field from the “DHCP REQUEST” packet.
Second
If “.DhcpEnable = true;” then “.DynamicDnsEnable = false” will be ignored. Those.
If we want to manually set DNS servers for example primary “8.8.8.8” and secondary “8.8.4.4”. And the server via DHCP returns the primary DNS for example “192.168.0.2”, then it will be used instead of “ours”. The interface settings will be primary “192.168.0.2” and secondary “8.8.4.4”.
If the DHCP server also returns a secondary DNS, for example “192.168.0.22”, then it will also be used instead of “ours”. The interface settings will be primary “192.168.0.2” and secondary “192.168.0.22”.
Thus, manually set DNS settings are not fixed after changes by the DHCP server.