Closed lyager closed 5 months ago
I've had issues with embedded devices changing IP's and appearing with both the previous and current IP. I'm guessing this goes for other records too?
Thanks for the response, I'll dive into it 👍
I had some trouble constructing a proper test. My idea was to start browsing, similar to the test service_with_temporarily_invalidated_ptr
, but I had trouble constructing response packets. I'll give it another shot, but if you have some test code where MDNS response packets are constructed and send out, please let me know :)
Broke a test putting into draft while looking at it.
I had some trouble constructing a proper test. My idea was to start browsing, similar to the test
service_with_temporarily_invalidated_ptr
, but I had trouble constructing response packets. I'll give it another shot, but if you have some test code where MDNS response packets are constructed and send out, please let me know :)
service_with_temporarily_invalidated_ptr
is a good sample to start. The response packet is constructed in to_packet_data
called by broadcast_dns_on_intf
. And you want to add CLASS_CACHE_FLUSH
when creating a record (valid record instead of the invalid one in below):
And a different, possible simpler approach is to construct a DnsCache
directly, and then call its add_or_update
and verify if the changes are applied.
I fixed the already existing test. Thanks for the help with understanding, I'll attempt writing a specific cache-flush test now.
Test added for cache flush - hope it's ok.
Thanks for the feedback, I've stoppede squashing the commit, if you prefer me to, let me know.
According to RFC 6762, when the cache-flush bit is set on a RR, all previously cache entries should be set to expire 1 second in the future.
This bit was previously called 'UNIQUE` which might have the same meaning, but cache-flush seems more in line with the RFC