Not able to set TLL in mDNS library

[cansik]

As written in the readme of the mDNS library, there should be a parameter to set the time to live (TTL) for the DNS entry:

mDNS Readme

But there is not parameter to set TLL and if you take a look at the source code, there is a constant value of 1 (shouldn't it be seconds?!).

static const int MDNS_MULTICAST_TTL = 1;

I could not find the source code for UdpContext, which receives this constant value. Does it receive seconds or hours?

if (!_conn->listen(*IP_ADDR_ANY, MDNS_PORT)) {
      return false;
    }
    _conn->setMulticastTTL(MDNS_MULTICAST_TTL);
    _conn->onRx(std::bind(&MDNSResponder::update, this));
    _conn->connect(multicast_addr, MDNS_PORT);

ESP8266mDNS.cpp#L2

What do you think about a method overload to define the TTL?

[philbowles]

In the header file is the following prototype:

bool begin(const char* hostName, IPAddress ip, uint32_t ttl=120){ (void) ip; (void) ttl; return begin(hostName); }

Which would seem like it does what you want it to do...but I have another issue on the same lines:

OTA calls MDNS.begin to put in the _arduino._tcp entries it appears that it does so with a TTL of 120

I am having problems (discussed elsewhere) with "stale" and/or duplicate records (which occur in my testing quite often - yes, my bad, I'm slack) . These "edge" cases cause my raspberry pi / NODE-RED to choke...with an "unknown dns error"

Thus when I add my services AFTER OTA - I'm also getting the default TTL of 120 of course.

I'd like to shorten my TTL drastically during testing. Thus I'd like a function to end MDNS. For historical reasons (I guess) the object is included "for free" when you include the library and is therefore at global scope and thus can't be "descoped" (without a reboot :) )

OR can someone reaasure me of any of the following:

1. If I call MDSN.begin(blahname,blahip,10) BEFORE OTA, will the OTA still function correctly and request a TTL of 120 for its own services?
2. If 1) then should I be OK to just do another MDNS begin as above with my shorter TTL (lazily I haven't tested that myself yet)
3. do either of .update() or .notifyAPChange() have the equivalent effect as my desired end function?

In short, what is the best (recommended) way of getting a shorter TTL while not side-effecting OTA?

I hope that all made sense...

[philbowles]

UPDATE:

repeating the MDNS.begin with the shorter TTL after the OTA call seems to work. "things" appear and disappear (roughly) within the 1 minute TTL I used. I'm preceding the call with .notifyAPChange and .update and will do some more testing later as to whether these are needed.

AND

I may have tracked down the situation that causes the mDNS "unknown dns error" on NODE-RED:

Steps to avoid / repeat:

1. bring "thing" online
2. srv appears in mdns list, discovery works 100%
3. takes it offline, wait at least two TTL periods, bring it back online, discovery again 100%

to repeat, perform steps 1 & 2, but this time:
3. run discovery before at least two TTL periods expire...NODE-RED dns error.

So the error seems to occur when the device is not "pingable" but a stale / dying / unexpired service record still exists for it.

I hope this helps anyone else with a similar problem!

[danieljharris]

I'm also having issues setting the TLL. What ever I do I can't seem to make any "answers" time out and update.

I "installServiceQuery" but it never seems to update. Leading to all the answers being outdated.

I've looked at the source code as best as I can but can't seem to figure out whats happening with the TTL. Would really appreciate it if someone could explain how to set the TTL correctly/find out if there is a bug stopping it being set correctly.

[Verwalter2017]

I am having a related issue:

My device is reachable via the local domain for some time after the start, but if I keep it running, the domain expires.

How to prevent that?
calling .update() doesn't seem to be enough. Do you need to call .begin() after TTL time is over?

[d-a-v]

@LaborEtArs do you think this line could be the source of this bug ?

My device is reachable via the local domain for some time after the start, but if I keep it running, the domain expires.

[Verwalter2017]

I am having the exact same issue:

My device is reachable via the local domain for some time after the start, but if I keep it running, the domain expires.

Same goes for ArduinoOTA - works fine if the device is freshly started, but after running some time it wont work, device isn't discovered anymore - mDNS Explorer ( I use "Avahi Discovery") doesn't show the service anymore.

How to fix this? Call .begin() again after TTL time is over?

[LaborEtArs]

@Verwalter2017 @danieljharris
The TTLs for host and service records are specified in the mDNS RFC 6762 (120s for host, 4500 for service records). These values are implemented in the responder. The 'begin' version, with TTL parameter was taken over from the legacy mDNS version for compatibility reasons and the parameter is ignored (as it was in the legacy version).
The reason for the ESP device not being reachable after a short period (I'd guess less than 120s) is most probably somewhere else. Another device looking for the ESP should update its knowledge about the ESP at least after the TTL has timed out; recommended is an earlier update. Most probably the ESP doesn't respond to this update call (or the call isn't sent at all).
Does anyone of you link against the IPv6 version of the lwip library?
PS: A call to 'update' is needed in the loop; 'begin' should only be called once
PPS: Mostly unrelated to this topic, but there is another 'TTL' around: The IP-TTL, which controls the number of network segments through which a IP packet is routed. For mDNS packets (which are local link packets) only the local network segment should be used (TTL=1), however, there are documents that say 255 (worldwide) is the right number. In fact I don't know... currently 255 is implemented (to be on the safe side)...

[d-a-v]

There are different meanings for "Time To Live".

• TTL value of an IP packet (unit = 'hop') is decreased when the packet is forwarded by a router (and dropped when the value reaches 0). mDNS packets are never routed, so IP TTL value could be any, there's no effect.
  UDP TTL is the IP TTL: the max 'hop' number on the route through destination.

• TTL (unit = seconds) mentioned in OP: It's the duration of a DNS cache entry.

As @LaborEtArs says, hop is unrelated with duration (in OP).
To all, can you provide MCVEs or run provided mDNS examples (preferably with latest git master) and check whether you can reproduce your issue ?

[devyte]

As @LaborEtArs explains, the paramater isn't supposed to be given by the user, and the signature is kept only for backwards compat.
The dropouts were likely caused by a stability issue that I think was addressed by #6484 . My own tests on mdns in my network show stable operation over close to 100 devices over several weeks.
Closing this.