[LEDE-DEV] umdns - TTL restricted to 255

[John Crispin]

in that case its a bug and the code should be changed to only have that 
restriction on queries

     John


On 25/09/17 17:21, Philipp Meier wrote:
> My question is about query (not response). LEDE is ignoring query when 
> TTL != 255.
>
> Philipp
>
>
> On 09/25/2017 05:16 PM, John Crispin wrote:
>> Hi,
>>
>> rfc6762 has the following ...
>>
>> 11.  Source Address Check
>>
>>    All Multicast DNS responses (including responses sent via unicast)
>>    SHOULD be sent with IP TTL set to 255.  This is recommended to
>>    provide backwards-compatibility with older Multicast DNS queriers
>>    (implementing a draft version of this document, posted in February
>>    2004) that check the IP TTL on reception to determine whether the
>>    packet originated on the local link.  These older queriers discard
>>    all packets with TTLs other than 255.
>>
>>     John
>>
>>
>>
>> On 25/09/17 16:44, Philipp Meier wrote:
>>> Hi,
>>>
>>> When using umdns I was wondering why my mDNS query did not get any 
>>> answer.
>>>
>>> I found the following reason:
>>>
>>> My mDNS query has TTL field set to 1. But LEDE umdns package expects 
>>> a TTL value of 255 (see interface.c function read_socket4).
>>>
>>> According 
>>> https://www.systutorials.com/docs/linux/man/5-avahi-daemon.conf/ 
>>> (see check-response-ttl) this was necessary security behavior in 
>>> older mDNS versions but will be incompatible with newer versions of 
>>> mDNS implementations.
>>>
>>> Therefore my question here is: Is this by purpose restricted to 255 
>>> by LEDE umdns package or could this be changed?
>>>
>>> Regards
>>> Philipp
>>>
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev