Support for mDNS with ip.ttl=255 and LLMNR ip.ttl > 0, not to show invalid TTL

This issue was migrated from bug 3965 in our old bug tracker.

Original bug information:

Reporter: Ivan Sy
Status: RESOLVED FIXED
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: All
Version: 1.2.1

Attachments:

mdns-ttl255-and-llmnr-ttl-any.patch: mdns-ttl255-and-llmnr-ttl-any.patch
mdns-llmnr.cap: mdns-llmnr.cap

Ivan Sy said:

Created attachment 3588 mdns-ttl255-and-llmnr-ttl-any.patch

Build Information: Version 1.3.0-SVN-29532

Copyright 1998-2009 Gerald Combs <gerald@‍wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.16.5, with GLib 2.20.4, with WinPcap (version unknown), with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8, with c-ares 1.6.0, with Lua 5.1, without Python, with GnuTLS 2.8.1, with Gcrypt 1.4.4, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Aug 28 2009), with AirPcap.

Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1 beta5 (packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS 2.8.1, Gcrypt 1.4.4, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

Support for mDNS with ip.ttl=255 and LLMNR ip.ttl > 0, not to show invalid TTL

- mDNS SHOULD be sent with TTL set to 255
- LLMNR - May be set to any value
- revised comment.

this report is in relation to bug#3814
please see attached update to
local_network_control_block_addr_valid_ttl



---
sec 4 http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-07

   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 clients that check
   the IP TTL on reception to determine whether the packet originated
   on the local link. These older clients discard all packets with TTLs
   other than 255.

   A host sending Multicast DNS queries to a link-local destination
   address (including the 224.0.0.251 link-local multicast address)
   MUST only accept responses to that query that originate from the
   local link, and silently discard any other response packets. Without
   this check, it could be possible for remote rogue hosts to send
   spoof answer packets (perhaps unicast to the victim host) which the
   receiving machine could misinterpret as having originated on the
   local link.

...
sec 8 http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-07

Multicast DNS
   Responses MUST be sent to UDP port 5353 (the well-known port assigned
   to mDNS) on the 224.0.0.251 multicast address (or its IPv6 equivalent
   FF02::FB).

---

sec 2 RFC 4795
   LLMNR queries are sent to and received on port 5355.  The IPv4 link-
   scope multicast address a given responder listens to, and to which a
   sender sends queries, is 224.0.0.252.

sec 2.5 RFC 4795
   For UDP queries and responses, the Hop Limit field in the IPv6 header
   and the TTL field in the IPV4 header MAY be set to any value.
   However, it is RECOMMENDED that the value 255 be used for
   compatibility with early implementations of [RFC3927].

see Appendix A.3 of RFC 3927 as well..

...

http://www.iana.org/assignments/multicast-addresses/

added uigtk version1.2 labels

Ivan Sy said:

Created attachment 3590 mdns-llmnr.cap

Jörg Mayer said:

I committed a different fix with r29644. Thanks for the report and proposed fix!

closed